[LLVMdev] possible target inpdependent changes to support mips16 and arm thumb

Reed Kotler rkotler at mips.com
Tue Oct 2 09:42:14 PDT 2012

I'm starting to look more seriously at the problem of being able to 
running TargetLowering on a per function basis.

In particular, I want to be able to compile functions as mips16 or 
mips32 , mixing them within a single compilation unit.

It would be great if some more experienced people in this overall 
structure of the compiler would give their 2c because I'd hate to spend 
a lot of time on it and realize that what I'm doing is a non starter for 
others. I don't have any doubt that I can get this to work but maybe 
people have thought about this and already have strong opinions as to 
how it should be done.  I'm usually just making changes in the Mips port.

Here are some things I want to be able to do:

1) Have the target lowering class created anew for each function; and as 
part of that I want to
be able to see some info from earlier phases before starting. So an 
attribute on a function may be "mips16" or "mips32", where the 
programmer has already decided what they want.

2. Have the ability to compile the same function two or more times and 
decide after which one
to keep for the final output. For example, compile with mips32 and 
mips16 and see which one is smaller. In principle mips16 will be smaller 
but floating point is difficult to do in mips16 and the limited register 
set could cause lots of spilling in some situations.

3) Be able to run pre-passes that try and determine a best guess for 
whether to compile a function as mips32 or mips16. There are some 
chicken and egg problems here. In PIC mode, mips16 has some advantages 
because there are real pc relative instructions whereas for Mips32, when 
you call a mips32 function, you have to explicitly pass the address of 
the callee in a fixed register so that it can figure where the GOT is. 
You can reduce the register pressure if don't have this as part of the 
call setup.

Currently, at least in the mips port, we are making decisions as to 
register classes and such in the constructor for the mips target 
lowering class.

More information about the llvm-dev mailing list