[llvm-commits] [PATCH] review request: [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

[Carter, Jack]

Hello Jim,

So does that mean you also approve of the concept of the patch that exposes ELFObjectWriter so I can get to the <target>ELFObjectTargetWriter from the streamer?

I have reattached it.

Jack
________________________________
From: Jim Grosbach [grosbach at apple.com]
Sent: Thursday, January 17, 2013 4:34 PM
To: Carter, Jack
Cc: llvm-commits at cs.uiuc.edu; rafael.espindola at gmail.com; Eli Bendersky
Subject: Re: [PATCH] review request: [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

Hi Jack,

I'm really not sure what I can tell you that I haven't already gone over. No, you're not going to find an exact example of precisely what you need anywhere that you can copy from. There are, however, examples of different parts of what you'll need to pull together.

Information is passed to the object writers via the object streamers. That's the interface you should be working with. When there's new information to pass through, a new interface is added to the appropriate streamer, which then passes it along to the writer. How the compiler gets the information to know what to pass to those streamer methods doesn't have to be (and often isn't') the same as how the assembler gets that information. For example, the compiler often can get answers to questions from metadata, TargetData and the like which the assembler may not have access to. The assembler will often use directives in the code to get the same information. In cases like that, the AsmStreamer should also be enhanced so that it will emit those directives when the compiler hits those Emit* calls to the streamer, enabling .s file output from the compiler to then be assembled with the resultant file having the metadata be intact. The ARM .eabi_attribute stuff partially implements this, though it uses EmitRawText for the asm streamer portion, and it really shouldn't have to do that.

The core design is that the Streamer interface is how the tools talk to the MC layer and provide information to it. The derived streamer classes (object streamers, asm streamers, etc) then package up that data and hand it off to whatever needs it (object writers, vanilla file I/O, etc). You don't need to add generic storage on the base classes to do any of this, and that's very intentional.

-Jim

On Jan 4, 2013, at 6:20 PM, "Carter, Jack" <jcarter at mips.com<mailto:jcarter at mips.com>> wrote:

Jim,

Happy new year.

I still need to pass ELF e_header information somehow to MipsELFObjectWriter. This includes the relocation model the chip level and any processor extensions along with xgot use.

I don't see any target, including ARM, doing what I need here. How do I get this information accessible to MipsELFObjectWriter? My patch does this, but I will take another path if it works.

As an experiment I exported MCObjectWriter and created an accessor method to hand over a pointer to MCELFObjectTargetWriter which can be cast to MipsELFObjectWriter. This works fine and doesn't require MCSubtargetInfo at all, but I fear that exposing the declarations in lib/MC/ELFObjectWriter is a non-starter. I'll attach a sample patch for reference.

In the case of my MCSubtargetInfo patch, I don't see where there is a place for all of the information I need. We don't store the relocation model (PIC/CPIC/STATIC) there nor in the features list. Thus the new data member.

This has to work for both llc and llvm-mc.

Regards,

Jack

________________________________
From: Jim Grosbach [grosbach at apple.com<mailto:grosbach at apple.com>]
Sent: Friday, December 21, 2012 4:01 PM
To: Carter, Jack
Cc: llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
Subject: Re: [PATCH] review request: [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter

Hi Jack,

There is no such class as "SubtargetInfo". There is MCSubtargetInfo and TargetSubtargetInfo. Please be very, very careful to indicate which you're talking about. The distinction is not arbitrary.

As to the additional data member, I'm unconvinced it's necessary. Targets already do target-specific things with regards to the object file writers (ARM, for example).

Likewise, why does the ELFObjectWriter need the MCSubtargetInfo? Any sub target information is, by definition, target specific and should already be available to the backend (assembler or compiler) whenever the object writer needs such information. For a rough example on the compiler side, ARMAsmPrinter::emitAttributes().

-Jim



On Dec 21, 2012, at 3:07 PM, "Carter, Jack" <jcarter at mips.com<mailto:jcarter at mips.com>> wrote:


SUMMARY:
This patch adds the SubtargetInfo 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 SubtargetInfo class object. This patch
passes the const reference 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 SubtargetInfo *STI) {
  return new MipsAsmBackend(T, Triple(TT).getOS(),
                            /*IsLittle*/false, /*Is64Bit*/true, STI);
}

I believe we could reduce this to the one parameter STI
and derive the rest of the information from it. I also
believe that STI could be used with the other MC classes
to reduce the need for future parameters there as well.

Since llc and llvm-mc use SubtargetInfo differently I have
added a new data member to SubtargetInfo that is a set of
integers for passing information. This data member may be
extended to allow a set of unions so wome other object,
but until there is a need for it, I want to keep it simple.

The tags for the sets are target specific so what ARM would
use it for would be different than for Mips if they want.

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.


Contributer: Jack Carter

<elf_header.patch><elf_header_clang.patch>

<new_eheader.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130118/e1d4d6d0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_eheader.patch
Type: text/x-patch
Size: 37748 bytes
Desc: new_eheader.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130118/e1d4d6d0/attachment.bin>