[PATCH] D21809: [SystemZ] Add support for .insn and .word/.short/.long/.quad directives

[Ulrich Weigand via llvm-commits]

uweigand added a comment.

> From my understanding, gas only supports some of the possible s390 instruction formats when using ".insn". For example, the "ri" format in the insn directive corresponds to the RI-a format, which uses an immediate field and not a relative-immediate field. Therefore, for the .insn directive specifically:

> 

> ri = RI-a

>  rie = RIE-d

>  ril = RIL-a


Well, sort of ... it is true that each .insn format corresponds to one specific s390 subformat, but for the most part, you can also use .insn to encode other subformats, e.g. by passing a mask in a register field, or by setting a field to 0.  Existing code using inline asm does that ...

However, there are a few subformats that indeed currently cannot be encoded, e.g. RI-b or RI-c, the RI variants with a PC-relative operand.  So my earlier comment was indeed not quite correct.

Looking at those formats again:

RIE: .insn directly models RIE-e, which is only used by BRXLG/BRXHG, which LLVM does not current have (but probably should).  However, we can also map the RIE-b format as long as M3 is hard-coded in the opcode (which is used by CRJ et al), or the RIE-c format as long as I2 is hard-coded (which is used by CIJ et al).  We can use a test using one of those to ensure the operand encoding works correctly.  [ I mentioned RxSBG, but those actually cannot be encoded since the .insn rie format always has a PC-relative operand. ]

RRF: all variants (RRF-a ... RRF-e) can be modeled (as long as can we pass a mask in a register field), so really any of the RRF instructions can be used here.  Most of those only use three fields, so in order to test all four we should use one of floating-point insns like LEDBRA.

RSE: in z/Architecture those are all now RSY, really ... so to test that .insn rse works, we can use any of the RSY instructions but simply only provide a short displacement

SS: this is indeed a bit difficult ... there are many SS subformats, and the instructions we currently support in LLVM (MVC etc) use the 8-bit length field, which cannot easily be represented with the .insn ss format


http://reviews.llvm.org/D21809