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

David Greene dag at cray.com
Tue Oct 7 09:14:45 PDT 2008

On Tuesday 07 October 2008 06:57, 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

Hmm, it seems I've been here before...  :)

> 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.

I did the once-per-module solution to this exact problem.  Here's what it 
looks like:

class RA {
    const TargetMachine* tm_;
    const TargetRegisterInfo* tri_;
    const TargetInstrInfo * tii_;
bool RA::runOnMachineFunction(MachineFunction &fn) {
  mf_ = &fn;
  tm_ = &fn.getTarget();
  tri_ = tm_->getRegisterInfo();
  tii_ = tm_->getInstrInfo();

  if (!initialized) {
    initialized = true;

The "initialized" flag is there to make sure it only happens once per module.  
You need a MachineFunction to get at the target info so I don't think it can 
be done in doInitialization.


More information about the llvm-dev mailing list