[LLVMdev] Getting target machine specific information at run-time

Devang Patel dpatel at apple.com
Tue Oct 7 10:09:47 PDT 2008

On Oct 7, 2008, at 4:57 AM, Roman Levenstein wrote:

> Hi,
> I'm playing with some experimental register allocators for LLVM. One  
> of them needs to build a so-called register
> class tree for representing the aliasing information among register  
> classes.
> This tree is not function or module specific. It is actually target  
> specific, because it depends only
> on the register classes defined for a machine that is used as a  
> target of the current compilation.
> I'd like to be able to compute this information only once during the  
> run-time, e.g. when target machine information is being created.
> But I couldn't find out how it can be done. Then I thought that it  
> should be possible to do it in the doInitialization() function of my  
> MachineFunctionPass.
> Then it would be done once per LLVM module, which is still  
> acceptable. I almost implemented this solution, but I have problems  
> accessing
> the architecture dependent bits of the Module, i.e. TargetMachine  
> objects specific for the current architecture, as selected by the -- 
> march option of the compiler.
> I tried using the getClosestTargetForJIT and  
> getClosestStaticTargetForModule functions of the  
> TargetMachineRegistry class.
> But all that was without success. I always get back only X86-based  
> targets (which is the target architecture of my development machine)
> even though I explicitly select another target for cross-compilation  
> by doing --march=sparc or --march=alpha.
> Could someone explain, what is a correct way to:
> 1) obtain a TargetMachine object related to the target selected  
> using --march option?

llc tool does this.

> 2) compute some target specific data once per compilation/per module  
> and use it in the machine pass(es)?

Write an immutable pass, TargetData is one example.

>    Is putting this computation into the doInitialization() function  
> a proper approach?

It is not a good idea to put this in doInitialization().


More information about the llvm-dev mailing list