[llvm-commits] [PATCH] Review request: MC access to target and subtarget machine info

[Jim Grosbach]

Hi Jack,

TargetMachine is deliberately not available in any MC layer code, as it's part of the CodeGen layer.

You probably want something along the lines of the features bit mask in MCSubtargetInfo. The ARM assembler has some examples of using that for related things.

-Jim

On Dec 3, 2012, at 11:48 AM, "Carter, Jack" <jcarter at mips.com> wrote:

> SUMMARY:
> This patch adds the <target>TargetMachine class 
> object to the creation of the <target>MCAsmBackend
> class object.
> 
> PROBLEM:
> The problem I have been having for some time is how
> to get access to target specific information during
> the direct object output phase. The current issue was
> how to fill the ELF header's target specific E_FLAGS
> bit field.
> 
> SOLUTION:
> The information has already been collected and isolated
> by the <target>TargetMachine class object. This patch
> passes the const pointer to this class object to the 
> <target>MCAsmBackend class object which in turn passes 
> it to the <target>ELFObjectWriter class object which
> updates the E_FLAGS.
> 
> This is the current creation routine for the backend:
> 
> MCAsmBackend *llvm::createMipsAsmBackendEB64(const Target &T, StringRef TT,
>                                              StringRef CPU,
>                                              const TargetMachine *TM) {
>   return new MipsAsmBackend(T, Triple(TT).getOS(),
>                             /*IsLittle*/false, /*Is64Bit*/true, TM);
> }
> 
> I believe we could reduce this to the one parameter TM 
> and derive the rest of the information from it. I also
> believe that TM could be used with the other MC classes
> to reduce the need for future parameters there as well.
> 
> An alternative and maybe cleaner solution would to create
> another class object, call it MCTarget for now, That would
> be filled at about the same time as SubtargetInfo and filled
> independently by the individual targets with just what they
> want. This might be more acceptable to the llvm-mc folks. I'd
> still want to load it with TM from a MCTarget method initially
> because the info is there.
> 
> For now, TargetMachine/SubtargetInfo have already derived 
> all that I need, albeit with a load of stuff I don't need
> as well.
> 
> CAVEAT:
> llvm-mc and clang both create MCAsmBackend separate from
> the general mechanism. In this patch I pass 0 (NULL) and 
> check for it before using the <target>TargetMachine object
> pointer. That is also why I use a pointer instead of a reference.
> 
> This will be fixed in a later patch.
> 
> CONCLUSION:
> * This patch does not affect the current behavior of other
>   targets.
> * Future E_FLAGS additions will be easy to implement at the
>   individual target level.
> * This change has changes in both the llvm and clang trees.
> * it would be followed up with patches for llvm-mc and clang.
> 
> Contributer: Jack Carter
> 
> <elf_header.patch><elf_header_clang.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121203/59bc92b8/attachment.html>