[LLVMdev] string input for the integrated assembler

Joerg Sonnenberger joerg at britannica.bec.de
Wed Mar 18 13:47:33 PDT 2015

On Wed, Mar 18, 2015 at 11:57:27AM -0700, Steve King wrote:
> We can use X86 for a meaty example that is close to my target.  In
> X86InstrInfo::optimizeCompareInstr() we see code like this:
>     case X86::SUB64ri32: NewOpcode = X86::CMP64ri32; break;
>     case X86::SUB64ri8:  NewOpcode = X86::CMP64ri8;  break;
>     case X86::SUB32ri:   NewOpcode = X86::CMP32ri;   break;
>     case X86::SUB32ri8:  NewOpcode = X86::CMP32ri8;  break;
>     case X86::SUB16ri:   NewOpcode = X86::CMP16ri;   break;
>     case X86::SUB16ri8:  NewOpcode = X86::CMP16ri8;  break;
>     case X86::SUB8ri:    NewOpcode = X86::CMP8ri;    break;

Note that as the name suggests, this is a peep hole optimisation for the
compiler, not for the assembler. So again, what are you worried about?
Parsing assembler or generating code?

There are a lot of optimisations for making it easier to express peep
hole optimisations in tblgen, but depending on the backend working on
such infrastructure is just not worth the time.

> My target has *many* more choices than just "ri" and "ri8" and checks
> like this switch statement would explode.  At the time of
> optimizeCompareInstr(), nitpicking all the various ways to encode an
> immediate value for an instruction would be very painful.  It's enough
> to know an immediate form exists as represented by a pseudo.  I get to
> use something like this:

So use tblgen to create appropiate pattern tables.

> Into the assembly output file, the pseudo emits something like:  "cmpl
> $0x80,%eax" with no clue of encoding.

For code generation it is often quite important to know the encoding as
different immediates have different costs associated with them. For many
of the RISC backends, it changes the number of instructions. That has
direct impact on other optimisations. As I mentioned, i.e. ARM has a
pseudo syntax for loading constants via "constant islands". PPC has
pseudo instructions for creating a 64bit immediate in a register via
sequence of shifted immediate and ors. I still don't know how your
target differs to offer more specific hints. 


More information about the llvm-dev mailing list