[llvm-commits] Patch for encodings of VEXT (Vector Extract)
Bob Wilson
bob.wilson at apple.com
Tue Oct 20 11:57:55 PDT 2009
Is this really the direction we want to go? There are a fair number
of NEON instruction encodings where it is very useful to have some
default bits set to zero by the .td file, assuming that the code
emitter may overwrite them later. For example, the vector shift-
immediate instructions have the "imm6" field that specifies both the
vector element size and the shift amount, where the number of bits
used for the shift amount varies depending on the element size. See
VSHR, for example. It is useful to specify the element size in
the .td file and it is a lot more convenient to do that by stuffing
zeros
into the shift amount.
Another example of this is the set of NEON instructions using the "One
register and a modified immediate value" format (A7.4.6). Currently
we've only got the VMOV variant implemented in LLVM. Some of the bits
in the "cmode" field can be set in the .td file but some depend on the
immediate value.
It's not a big problem to have a special N3VImm format for VEXT, but
it seems like we might need a different solution for the general
problem, regardless of what we do for VEXT. Is it important that you
leave those bits unspecified? You didn't say why the patch was needed.
On Oct 16, 2009, at 11:17 AM, Johnny Chen wrote:
> Hi,
>
> Refs: A8-598.
> Leave Inst{11-8}, which represents the starting byte index of the
> extracted result in the
> concatenation of the operands and is left unspecified.
>
> <ARMInstrNEON.patch5>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list