[PATCH] D13193: Add an MCTargetMachine and use it to configure MCAsmInfo

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 8 18:31:41 PDT 2015


echristo added a reviewer: grosbach.
echristo added a comment.

Hi Daniel,

It looks like what you've done is take a wrapper around Triple and propagate it - basically redoing some of the TargetTuple work and just calling it MCTargetMachine. :)

It wasn't quite where I was going though, let me try and explain by taking a look at some of the normal TargetMachine class contents:

  /// Low level target information such as relocation model. Non-const to
  /// allow resetting optimization level per-function.
  MCCodeGenInfo *CodeGenInfo;
  
  /// Contains target specific asm information.
  const MCAsmInfo *AsmInfo;
  
  const MCRegisterInfo *MRI;
  const MCInstrInfo *MII;
  const MCSubtargetInfo *STI;

Where we've actually got a lot of the information you're passing your wrapped Triple into. The idea that I was trying to get across is that the MCTargetMachine should serve as the base holder class for a lot of this information and would be initialized similarly to the various TargetMachines, but with MC level equivalents where it matters, e.g. MCTargetOptions, etc.

If you look at MCTargetOptions, for example, it even has this:

  /// getABIName - If this returns a non-empty string this represents the                      
  /// textual name of the ABI that we want the backend to use, e.g. o32, or                    
  /// aapcs-linux.                                                                             
  StringRef getABIName() const;
  std::string ABIName;

which will serve as a good way of solving your "I don't have the ABI" problem that you were mentioning before - as long as argument parsing will set it correctly when constructing MCTargetMachine.

Does this make sense? Seem like it's going the right direction to you?

-eric


http://reviews.llvm.org/D13193





More information about the llvm-commits mailing list