[LLVMdev] CompositeIndices

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Apr 2 09:52:04 PDT 2012


On Mar 31, 2012, at 1:02 AM, Reed Kotler <rkotler at mips.com> wrote:

> Does anyone know exactly what ComposerIndices in Target.td is all about?
> 
> I see just one place where it's used in X86 but it's not clear from the 
> comments in Target.td and it's one usage, exactly what this feature is 
> about.

TableGen uses them when flattening the sub-register graph. The best example is the ARM NEON registers:

  D0 = { ssub0:S0, ssub1:S1 }
  D1 = { ssub0:S2, ssub1:S3 }

  Q0 = { dsub0:D0, dsub1:D1 }

The flattening means that Q0 has all six sub-registers:

  Q0 = { dsub0:D0, dsub1:D1, ssub0:S0, ssub1:S1, ?:S2, ?:S3 }

Each sub-register must have a unique sub-register index. If you don't specify any CompositeIndices, TableGen will invent names like dsub0_then_ssub_0. The CompositeIndices allows you to name the composite indices:

  CompositeIndices = [(ssub2 dsub_0, ssub_0), (ssub3 dsub_0, ssub_1)]

With that declaration, TableGen infers these sub-register names:

  Q0 = { dsub0:D0, dsub1:D1, ssub0:S0, ssub1:S1, ssub2:S2, ssub3:S3 }

It will also emit a composeSubRegIndices() function that tells you dsub1+ssub0 = ssub2 etc.


Sub-register indices are supposed to compose identically in all registers, so I found it was more convenient to specify the composition as part of the SubRegIndex def itself:

  def ssub_0  : SubRegIndex;
  def ssub_1  : SubRegIndex;
  def ssub_2  : SubRegIndex<[dsub_1, ssub_0]>;
  def ssub_3  : SubRegIndex<[dsub_1, ssub_1]>;

When you do that, it is no longer necessary to set CompositeIndices in the register definitions. I wanted to eliminate CompositeIndices completely, but there is one remaining use: The idempotent sub_ss and sub_sd indices on the XMM registers.

It is possible we can get away with this instead:

  let SubRegIndices = [sub_ss, sub_sd] in
  def XMM0: RegisterWithSubRegs<"xmm0", [XMM0, XMM0]>;

That would allow us to completely remove CompositeIndices.

/jakob




More information about the llvm-dev mailing list