- User Since
- Jul 12 2017, 1:23 AM (93 w, 16 h)
Wed, Apr 17
Tue, Apr 16
This infrastructure should be enough to let you use the vector types in C as a means of getting them to and from __asm__ blocks that do the real work. I suppose that means I should include some tests that exercise exactly that, using asm operations in IR.
It's tested for v8.1-M, by llvm/test/MC/ARM/thumbv8.1m.s which is added by D60706. I could add an extra test or two to this patch for other affected architectures, if you think it's necessary.
The aim of this change is that it will apply to the v8.1-M (mainline) architecture introduced in D60698, in which +fp won't be the default: -march=armv8.1m.main by itself gives you the base 8.1-M architecture without any FP, -march=armv8.1m.main+fp gives you the optional single-precision FP extension on top of that, and +fp.dp gives you double precision as well.
Mon, Apr 15
It's true that during internal development we implemented this rename before the later change that adds some UnsupportedFeatures to the same schedule model which should rule out the MVE VMAXNM/VMINNM instructions in any case.
Yes, it is.
Fri, Apr 12
Adjusted message wording as suggested.
Thu, Apr 11
Mar 12 2019
Mar 11 2019
Simpler version that just replaces DenseMap with std::map.
I'm happy to do that if you prefer – I left the DenseMap in place on the Chesterton's Fence principle. (I didn't know why it was originally chosen over std::map, so hesitated to unilaterally reverse the decision.)
Mar 6 2019
Feb 25 2019
Feb 22 2019
I'm not as familiar with the NEON FP16 instructions, but in a quick
look I didn't see a corresponding issue with predicating them – e.g.
the vector vadd.f32 and vadd.f16 are just as predicable as each
other, unlike the scalar ones.
Feb 21 2019
Could I ping this, please? I've added the assembler check @efriedma asked about; is there anything else I need to change?
Feb 8 2019
Added an error check in ARMAsmParser and a test that exercises it.
Feb 7 2019
Good question. Testing it with llvm-mc, what seems to happen (with this patch applied) is that if I write one of these instructions after an explicit it instruction then I get "error: instructions in IT block must be predicable", but if there's no preceding IT then it's accepted without complaint.
Feb 6 2019
Jan 17 2019
Jan 8 2019
Jan 7 2019
Dec 14 2018
Could I give this a gentle ping, please?
Nov 28 2018
I've just come back to this patch after being distracted for several weeks (sorry about that). I intend to actually commit it shortly, and this time I'll try not to forget :-)
Nov 1 2018
Name is rewritten between creation of LHSOp and RHSOp, so you
can't just make both of them into StringRefs because LHSOp would be
invalidated by the change to Name.
Oct 31 2018
OK, here's a second draft which names the variables more sensibly. Perhaps slight overkill, in that I've used LHSOp and RHSOp for the variables ordered as they are in the source constraints string, and then DestOp and SrcOp once they're reordered to (what should be) a def and a use.
Oct 30 2018
Can you add some tests for the affected instructions?
Oct 29 2018
Aug 15 2018
Jul 13 2018
LGTM. (But I learned something new when I dug into lit to find out why you could get away with using single quotes – I would have expected that only double quotes would work on Windows!)
Jul 12 2018
Oops, sorry about that :-(
Jul 11 2018
Actually, on second thoughts, I'm going to assume it was overcautious to ask for a re-approval, since this version of the patch introduces no new controversy and in fact removes the only previous tweak in the Tablegen core (in that I'm not trying to change the semantics of anonymous any more). So I'll commit this as is, based on the previous review approval.
Jul 10 2018
Nearly forgot to mention the new option in the tblgen man page!