[llvm-dev] Dynamic selection of assembly mnemonic strings

Martin J. O'Riordan via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 8 04:24:05 PDT 2016


Hi LLVM Dev,

 

I have an old problem that I've wanted to clean-up for some time.  Our chip
has gone through a number of iterations in the past few years, but with each
revision there have been changes to some of the mnemonics for instructions.
These are mostly very simple, for example we had a 32-bit load from memory
instruction named 'LD32' in one version of the chip, but for a later version
this was changed to 'LD.32'.

 

The semantics and schedule remained the same, but in the TD file I had to
introduce two 'def's for this (actually, I abstract a bit more and use a
'defm'):

 

def LD32_v1 : Instr<... "LD32" ...>,  Requires<[isV1]>;

def LD32_v2 : Instr<... "LD.32" ...>, Requires<[isV2]>;

 

This all works fine, but there is a large number of them which makes
maintenance difficult.  This also adds to the burden of selection when using
'BuildMI' in the C++ code, as I have to do things like:

 

if (isV1())

  BuildMI(..., TII->get(SHAVE::LD32_v1)

else if (isV2())

  BuildMI(..., TII->get(SHAVE::LD32_v2)

 

What I would like, is for some mechanism that can substitute the version
specific mnemonic dynamically (perhaps using a lookup table), and I could
reduce the above to just:

 

def LD32 : Instr<... "??MetaMnemonic??" ...>;

and:

BuildMI(..., TII->get(SHAVE::LD32)

 

Does anyone know how this can be achieved without resort to placing some
Meta-Mnemonic for '??MetaMnemonic??' and replacing this with the version
specific value during AsmPrinting?

 

Some instructions have more elaborate substitutions, but the general
principle is the same and there are a large number of instructions that are
affected which makes the TD files very large, and the conditional 'BuildMI'
code overcomplicated.

 

Thanks,

 

            MartinO

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160708/2fe1097b/attachment.html>


More information about the llvm-dev mailing list