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

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com>
wrote:
> Eli,
>
> This is the kind of feedback I want. I believe I have to add to the base
class so it should be generally useful. I can see string being better for the
value. I still am enamoured with an enumeration for the tab though:
int->string. How would that be a limitation?
>
I guess that's fine, as long as you don't just limit it to binary
"has
/ hasn't flag".
> How about the rest of the patch?
>
There's one thing about it I'm not sure I understand. You are
essentially passing commands to the assembler via "target"
information. But how does this make sense? I realize that the flags
themselves (their kinds and possible values) are properties of the
target, but their passing to the assembler is not. In other words, I
would expect the assembler driver to propagate flags down to the ELF
writer in some manner which is not through the target object. The
target object is supposed to provide information about the target,
which does not depend on the particular invocation of the assembler
and the flags passed to it.

I hope the above is coherent; it not, feel free to demand another attempt.

Eli

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.

Cheers,

Jack

________________________________________
From: Eli Bendersky [eliben at google.com]
Sent: Friday, December 14, 2012 4:26 PM
To: Carter, Jack
Cc: Jim Grosbach; List
Subject: Re: [LLVMdev] [MC] [llvm-mc] Getting target specific information to
<target>ELFObjectWriter

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com>
wrote:
> Eli,
>
> This is the kind of feedback I want. I believe I have to add to the base
class so it should be generally useful. I can see string being better for the
value. I still am enamoured with an enumeration for the tab though:
int->string. How would that be a limitation?
>
I guess that's fine, as long as you don't just limit it to binary
"has
/ hasn't flag".
> How about the rest of the patch?
>
There's one thing about it I'm not sure I understand. You are
essentially passing commands to the assembler via "target"
information. But how does this make sense? I realize that the flags
themselves (their kinds and possible values) are properties of the
target, but their passing to the assembler is not. In other words, I
would expect the assembler driver to propagate flags down to the ELF
writer in some manner which is not through the target object. The
target object is supposed to provide information about the target,
which does not depend on the particular invocation of the assembler
and the flags passed to it.

I hope the above is coherent; it not, feel free to demand another attempt.

Eli

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