[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