This is an archive of the discontinued LLVM Phabricator instance.

[ARM,MVE] Revise immediate VBIC/VORR to look more like NEON.
ClosedPublic

Authored by simon_tatham on Jan 22 2020, 8:26 AM.

Details

Summary

In NEON, the immediate forms of VBIC and VORR are each represented as
a single MC instruction, which takes its immediate operand already
encoded in a NEON-friendly format: 8 data bits, plus some control bits
indicating how to expand them into a full vector.

In MVE, we represented immediate VBIC and VORR as four separate MC
instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or
24 bits. For each one, the value of the immediate operand is in the
'natural' form, i.e. the numerical value that would actually be BICed
or ORRed into each vector lane (and also the same value shown in
assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as
0xab0000, which NEON would represent as 0xab | (control bits << 8).

The MVE approach is superficially nice (it makes assembly input and
output easy, and it's also nice if you're manually constructing
immediate VBICs). But it turns out that it's better for isel if we
make the NEON and MVE instructions work the same, because the
ARMISD::VBICIMM and VORRIMM node types already encode their immediate
into the NEON format, so it's easier if we can just use it.

Also, this commit reduces the total amount of code rather than
increasing it, which is surely an indication that it really is simpler
to do it this way!

Diff Detail

Event Timeline

simon_tatham created this revision.Jan 22 2020, 8:26 AM
dmgreen accepted this revision.Jan 23 2020, 1:06 AM

Looks like this simplified quite a few bits of code. Thanks.

This revision is now accepted and ready to land.Jan 23 2020, 1:06 AM
This revision was automatically updated to reflect the committed changes.