[LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

[Eli Bendersky]

On Mon, Dec 17, 2012 at 3:17 PM, Carter, Jack <jcarter at mips.com> wrote:
> Eli,
>
> Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers.  Working with the current framework it seemed the least disruptive.
>
> I'll describe the problem again.
>
> The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object method that allows me to update the e_flags at the target level, <target>ELFObjectWriter::getEFlags(),  had no access to any target specific information .
>
> MipsELFObjectWriter is created during MipsAsmBackend construction which is create during an invocation of createMipsAsmBackend().
>
> create<target>AsmBackend is called by:
>   the codegen (integrated assembler)
>   llvm-mc (standalone assembler)
>   clang (cc1as_main.cpp)
>
> My solution for getting access of target specific data to <target>ELFObjecWriter was to pass a reference of SubtargetInfo to it through the <target>AsmBackend construction.
>
> For the integrated assembler this works well because what is really passed is a derived class of <target>Subtarget. I can add stuff to MipsSubtarget without affecting any other target. Here is the inheritance:
>   SubtargetInfo
>   TargetSubtargetInfo
>   <target>GenSubtargetInfo
>   <target>Subtarget
>
> <target>Subtarget is created through TargetMachine and is codegen centric.
>
> For the standalone assembler and the clang this isn't the case. A straight SubtargetInfo object is created.
>
> From here I added a single data member to the SubratgetInfo class that could be used as a message board so when one is in a method like MipsELFObjectWriter::getEFlags() one could access the information in a common manner.
>
> I made the message board a set with the tag being an integer so each target which chooses to use it could create their own enumerations for the stored info. My initial thought was to make it a set of ints because I just wanted to know if things were on or off, but maybe a set of pointers to templated unions would be more flexible although I do believe that this is overkill.
>

Hi Jack,

I understand your motivation here, as I mentioned earlier. It's just
that I don't like the current piping we have in LLVM to pass this
information around. I think that a lot of information is piggybacking
on the Target/Subtarget abstractions, just because these objects
already get pushed everywhere. I wouldn't expect you to turn the whole
infrastructure on its head just for the small changes you need
committed, so I have no objections to your patch. Not being the code
owner I can't formally approve it, of course.

Just a final suggestion: from a cursory look at the llvm-mc tool, it
passes relocation model flags to the streamers by means of a
MCObjectFileInfo object that gets added to MCContext. Could you by any
chance use this for your needs?

Eli