Page MenuHomePhabricator

[ARM] Code-generation infrastructure for MVE.
Needs ReviewPublic

Authored by simon_tatham on Apr 15 2019, 6:00 AM.



This provides the low-level support to start using MVE vector types
and predicated instructions in C source code:

  • spills, reloads and register moves for MVE vector registers
  • ditto for the VPT predication mask that lives in VPR.P0
  • make all the MVE vector types legal in ISel, and provide selection DAG patterns for LOAD and STORE
  • an extension of Thumb2ITBlockPass to spot MachineInstrs that list themselves as VPT-predicated, and add the actual VPST instruction above each one.

The VPT block generation is currently trivial: it only ever puts one
instruction in a block (no longer forms such as VPTTET), and it always
uses the VPST instruction (meaning 'predicate on whatever was already
in P0') as opposed to VPT ('do a comparison and immediately start a
VPT block based on the results').

Event Timeline

simon_tatham created this revision.Apr 15 2019, 6:00 AM

Can any of this be tested yet, or are we still missing some patches?


Style nit: opening brace should be on the line above.


Should we assert that the other register is a GPR here?


Does anything generate VPT-predicated instructions yet? If not, this should probably be split into a separate patch.

t.p.northover added inline comments.

Braces go on the same line as the ) in LLVM style.


I think this would be clearer if you used the isInt<7> functions from MathExtras.h.


I think this function would be a good place to assert that all instructions have at most one kind of predication.


This continue isn't needed with the new control flow (and is inconsistent with the other branches).


Possibly better as a static helper; then you don't have to explain it at all in the documentation comments in the header.

simon_tatham marked an inline comment as done.Apr 16 2019, 8:42 AM

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.


You have a point – predicated instructions won't be generated by anything I can think of in this patch series, and if you put one in an __asm__ block then it won't be represented in a way that this phase will notice.

So yes, perhaps I should back out this part of the patch until the ACLE intrinsics implementation is ready for review.