Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Daniel Sanders

Hi,

 

I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this.

 

It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving

MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.

 

Does anyone agree/disagree with this change? Have I missed anything?

 

Daniel Sanders

Leading Software Design Engineer, MIPS Processor IP

Imagination Technologies Limited

www.imgtec.com

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Ambuj Agrawal
I agree with the change but am not sure how it might affect other targets. I am fairly new to the LLVM backend.

Thanks,
Ambuj

On Thu, May 21, 2015 at 4:40 PM, Daniel Sanders <[hidden email]> wrote:

Hi,

 

I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this.

 

It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving

MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.

 

Does anyone agree/disagree with this change? Have I missed anything?

 

Daniel Sanders

Leading Software Design Engineer, MIPS Processor IP

Imagination Technologies Limited

www.imgtec.com

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Reid Kleckner-2
In reply to this post by Daniel Sanders
I think MCAsmInfo was really intended to describe this kind of stuff in the first place. The way I understand it, it's supposed to describe things like "what are the quirks of this target's assembler that I need to know", which includes the private label prefix. That said, it grew lots of other unrelated responsibilities, like "how does EH work on this target".

Why isn't the ABI reflected in the triple? Can you thread whatever selects the object file into down to whatever selects the asm info?

Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.

Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.

On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <[hidden email]> wrote:

Hi,

 

I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this.

 

It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving

MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.

 

Does anyone agree/disagree with this change? Have I missed anything?

 

Daniel Sanders

Leading Software Design Engineer, MIPS Processor IP

Imagination Technologies Limited

www.imgtec.com

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Daniel Sanders
> Why isn't the ABI reflected in the triple?

Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu
toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely possible for mips-foo-linux-gnu to produce 64-bit little endian binaries for Mips64r6 by default. Additionally, when given the -EL option, mips-linux-gnu will produce little endian binaries despite having a big-endian triple. The same applies to a lot of our code generation options. The most complicated one I'm aware of is mips-mti-linux-gnu which can produce code for nearly any Mips target when given the right options.

The main issue I have at the moment is with the N32 and N64 ABI's. These are ILP32 and LP64 respectively, are mutually incompatible, and have traditionally used the same triple.
There's an ARM example of the same problem at https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F. In that example, hard-float and soft-float both used arm-linux-gnueabi but were mutually incompatible. The Multiarch tuples described on that page are an attempt to resolve the ambiguity but I'm told that they aren't likely to be universally adopted.

Maybe, a better solution is to have a clean break from traditional triples and have a translation layer to convert traditional triples into a new set of unambiguous LLVM tuples. Ideally, frontends wouldn't have to worry too much about the details of this and can just set some options for the target and be told the correct LLVM tuple to use.

> Can you thread whatever selects the object file into down to whatever selects the asm info?

Sorry about this. I'm working on two very similar issues at the same time (this one and the exception TType encoding being ABI dependant) and I've mixed them together in my original email. The split I should have described is that the label prefix is '$' for O32 and '.L' for N32/N64. Unfortunately O32/N32 are ELF32 and N64 is ELF64.

I tried passing MCTargetOptions::ABIName down to the MCAsmInfo but ran into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know the ABI until it starts reading the object file but has to initialize the MCAsmInfo earlier than that. IRObjectFile was another problem area.

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: 22 May 2015 16:22
To: Daniel Sanders
Cc: LLVM Developers Mailing List ([hidden email])
Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

 

I think MCAsmInfo was really intended to describe this kind of stuff in the first place. The way I understand it, it's supposed to describe things like "what are the quirks of this target's assembler that I need to know", which includes the private label prefix. That said, it grew lots of other unrelated responsibilities, like "how does EH work on this target".

 

Why isn't the ABI reflected in the triple? Can you thread whatever selects the object file into down to whatever selects the asm info?

 

Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.

 

Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.

 

On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <[hidden email]> wrote:

Hi,

 

I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this.

 

It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving

MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.

 

Does anyone agree/disagree with this change? Have I missed anything?

 

Daniel Sanders

Leading Software Design Engineer, MIPS Processor IP

Imagination Technologies Limited

www.imgtec.com

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Jim Grosbach
ARM already has a similar problem, where the prefix on Darwin is not the same as it is on Linux. It sounds like your situation is a bit more complicated, though.

On May 22, 2015, at 11:49 AM, Daniel Sanders <[hidden email]> wrote:

> Why isn't the ABI reflected in the triple?

Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu 
toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely possible for mips-foo-linux-gnu to produce 64-bit little endian binaries for Mips64r6 by default. Additionally, when given the -EL option, mips-linux-gnu will produce little endian binaries despite having a big-endian triple. The same applies to a lot of our code generation options. The most complicated one I'm aware of is mips-mti-linux-gnu which can produce code for nearly any Mips target when given the right options.

The main issue I have at the moment is with the N32 and N64 ABI's. These are ILP32 and LP64 respectively, are mutually incompatible, and have traditionally used the same triple.
There's an ARM example of the same problem at https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F. In that example, hard-float and soft-float both used arm-linux-gnueabi but were mutually incompatible. The Multiarch tuples described on that page are an attempt to resolve the ambiguity but I'm told that they aren't likely to be universally adopted.

Maybe, a better solution is to have a clean break from traditional triples and have a translation layer to convert traditional triples into a new set of unambiguous LLVM tuples. Ideally, frontends wouldn't have to worry too much about the details of this and can just set some options for the target and be told the correct LLVM tuple to use.


This is the key question. The LLVM assumption is that these sorts of things are inferable from the triple. Your observation here that the GNU world’s notion of triples and LLVM’s need not be the same is a good one. Having a split and a translation up in clang seems an interesting avenue to explore. I suspect this won’t be the last of this sort of issue you’ll encounter, unfortunately. Smarter LLVM layer triples is very worth exploring. Darwin puts things like deployment target version numbers in the triple (arm64-apple-ios8.3, e.g.). Having something to distinguish between ELF32 vs. ELF64, or whatever else, be explicit in the LLVM triple seems reasonable.


> Can you thread whatever selects the object file into down to whatever selects the asm info?

Sorry about this. I'm working on two very similar issues at the same time (this one and the exception TType encoding being ABI dependant) and I've mixed them together in my original email. The split I should have described is that the label prefix is '$' for O32 and '.L' for N32/N64. Unfortunately O32/N32 are ELF32 and N64 is ELF64.

I tried passing MCTargetOptions::ABIName down to the MCAsmInfo but ran into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know the ABI until it starts reading the object file but has to initialize the MCAsmInfo earlier than that. IRObjectFile was another problem area.

 

From: Reid Kleckner [[hidden email]] 
Sent: 22 May 2015 16:22
To: Daniel Sanders
Cc: LLVM Developers Mailing List ([hidden email])
Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

 

I think MCAsmInfo was really intended to describe this kind of stuff in the first place. The way I understand it, it's supposed to describe things like "what are the quirks of this target's assembler that I need to know", which includes the private label prefix. That said, it grew lots of other unrelated responsibilities, like "how does EH work on this target".

 

Why isn't the ABI reflected in the triple? Can you thread whatever selects the object file into down to whatever selects the asm info?

 

Maybe MCAsmInfo should be completely folded into MCObjectFileInfo, or renamed if it no longer describes "assembly" information.

 

Anyway, this one change seems fine by itself. I'm mostly pointing out that this area needs a bit of cleanup.

 

On Thu, May 21, 2015 at 8:40 AM, Daniel Sanders <[hidden email]> wrote:
Hi,

 

I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this.

 

It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving
MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple.

 

Does anyone agree/disagree with this change? Have I missed anything?

 

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Renato Golin-2
On 23 May 2015 at 00:08, Jim Grosbach <[hidden email]> wrote:
> This is the key question. The LLVM assumption is that these sorts of things
> are inferable from the triple. Your observation here that the GNU world’s
> notion of triples and LLVM’s need not be the same is a good one. Having a
> split and a translation up in clang seems an interesting avenue to explore.
> I suspect this won’t be the last of this sort of issue you’ll encounter,
> unfortunately. Smarter LLVM layer triples is very worth exploring.

IIRC, some people were exploring moving all options to
-march/-mcpu/-mfpu and other -m options (like os, abi, release)
instead of using triples.

It'll be easier to convince other compiler to support -m options than
to support a whole new type of triple/tuple.

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Daniel Sanders
> -----Original Message-----
> From: Renato Golin [mailto:[hidden email]]
> Sent: 23 May 2015 11:19
> To: Jim Grosbach
> Cc: Daniel Sanders; LLVM Developers Mailing List ([hidden email])
> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to
> MCObjectFileInfo
>
> On 23 May 2015 at 00:08, Jim Grosbach <[hidden email]> wrote:
> > This is the key question. The LLVM assumption is that these sorts of things
> > are inferable from the triple. Your observation here that the GNU world’s
> > notion of triples and LLVM’s need not be the same is a good one. Having a
> > split and a translation up in clang seems an interesting avenue to explore.
> > I suspect this won’t be the last of this sort of issue you’ll encounter,
> > unfortunately. Smarter LLVM layer triples is very worth exploring.
>
> IIRC, some people were exploring moving all options to
> -march/-mcpu/-mfpu and other -m options (like os, abi, release)
> instead of using triples.
>
> It'll be easier to convince other compiler to support -m options than
> to support a whole new type of triple/tuple.
>
> cheers,
> --renato

The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal representation throughout LLVM and the LLVM-IR files. The end-users can still use GNU triples and compiler options such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM tuple.

As an example, here's a sketch of how I see the creation of MCAsmInfo changing in llvm-mc.cpp. At the moment it's:
        MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); // MCTargetOptions::ABIName set to the value of -target-abi
        TripleName = Triple::normalize(TripleName);
        Triple TheTriple(TripleName);
        ...
        std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TripleName));
        assert(MAI && "Unable to create target asm info!");
and it would become something like:
        MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); // MCTargetOptions::ABIName no longer exists
        TargetTuple TheTuple(GNUTriple(TripleName).getTargetTuple());
        ...
        // We can factor this block into a function
        if (... arguments have -EL ...)
          TargetTuple.setEndian(Little);
        if (...arguments have -mabi=X ...)
          TargetTuple.setABI(ABI);
        ... etc. ...
        ...
        std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TheTuple));  
        assert(MAI && "Unable to create target asm info!");
the user is still able to use GNU triples as they did before.

As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
        StringRef Triple = M->getTargetTriple(); // Currently a GNU triple.
        std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Triple));              
        if (!MAI)
          return;
        ...
        MCTargetOptions MCOptions; // MCTargetOptions::ABIName is not initialized since there are no arguments to parse.
As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
        TargetTuple Tuple(M->getTargetTriple()); // Now an LLVM tuple and contains the ABI name.
        std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Tuple));              
        if (!MAI)
          return;
        ...
        MCTargetOptions MCOptions; // MCTargetOptions::ABIName no longer exists.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Jim Grosbach

> On May 26, 2015, at 6:58 AM, Daniel Sanders <[hidden email]> wrote:
>
>> -----Original Message-----
>> From: Renato Golin [mailto:[hidden email]]
>> Sent: 23 May 2015 11:19
>> To: Jim Grosbach
>> Cc: Daniel Sanders; LLVM Developers Mailing List ([hidden email])
>> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to
>> MCObjectFileInfo
>>
>> On 23 May 2015 at 00:08, Jim Grosbach <[hidden email]> wrote:
>>> This is the key question. The LLVM assumption is that these sorts of things
>>> are inferable from the triple. Your observation here that the GNU world’s
>>> notion of triples and LLVM’s need not be the same is a good one. Having a
>>> split and a translation up in clang seems an interesting avenue to explore.
>>> I suspect this won’t be the last of this sort of issue you’ll encounter,
>>> unfortunately. Smarter LLVM layer triples is very worth exploring.
>>
>> IIRC, some people were exploring moving all options to
>> -march/-mcpu/-mfpu and other -m options (like os, abi, release)
>> instead of using triples.
>>
>> It'll be easier to convince other compiler to support -m options than
>> to support a whole new type of triple/tuple.
>>
>> cheers,
>> --renato
>
> The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal representation throughout LLVM and the LLVM-IR files. The end-users can still use GNU triples and compiler options such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM tuple.

Yep. I completely agree that having a significantly different user-facing triple structure would be a much different thing.

The advantage here is that we can put quite a lot of this translation stuff into per-target hooks and such (where it makes sense).

>
> As an example, here's a sketch of how I see the creation of MCAsmInfo changing in llvm-mc.cpp. At the moment it's:
> MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); // MCTargetOptions::ABIName set to the value of -target-abi
> TripleName = Triple::normalize(TripleName);
> Triple TheTriple(TripleName);
> ...
> std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TripleName));
> assert(MAI && "Unable to create target asm info!");
> and it would become something like:
> MCTargetOptions MCOptions = InitMCTargetOptionsFromFlags(); // MCTargetOptions::ABIName no longer exists
> TargetTuple TheTuple(GNUTriple(TripleName).getTargetTuple());
> ...
> // We can factor this block into a function
> if (... arguments have -EL ...)
>  TargetTuple.setEndian(Little);
> if (...arguments have -mabi=X ...)
>  TargetTuple.setABI(ABI);
> ... etc. ...
> ...
> std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TheTuple));  
> assert(MAI && "Unable to create target asm info!");
> the user is still able to use GNU triples as they did before.
>
> As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
> StringRef Triple = M->getTargetTriple(); // Currently a GNU triple.
> std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Triple));              
> if (!MAI)
>  return;
> ...
> MCTargetOptions MCOptions; // MCTargetOptions::ABIName is not initialized since there are no arguments to parse.
> As another example, here's the creation of MCAsmInfo in IRObjectFile.cpp:
> TargetTuple Tuple(M->getTargetTriple()); // Now an LLVM tuple and contains the ABI name.
> std::unique_ptr<MCAsmInfo> MAI(T->createMCAsmInfo(*MRI, Tuple));              
> if (!MAI)
>  return;
> ...
> MCTargetOptions MCOptions; // MCTargetOptions::ABIName no longer exists.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Renato Golin-2
In reply to this post by Daniel Sanders
On 26 May 2015 at 14:58, Daniel Sanders <[hidden email]> wrote:
> The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal representation throughout LLVM and the LLVM-IR files. The end-users can still use GNU triples and compiler options such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM tuple.

Ok, so that will probably involve the Triple / Parser refactoring I'm doing.

Right now, Triple handles some of that, but it's not authoritative not
final. I've created an ARMTargetParser class that deals with parsing
arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM
is done already) to it. We may also have to move llc, lli and others.

Once this is done, we can begin to move more logic to the Triple in
the same way, and let target specific Triple management in their own
classes (like ARMTargetParser), so that Clang doesn't need all
back-ends to have all arch knowledge. This way, the Triple class will
be able to take any architecture-specific decision with just strings.
Such arch-specific classes will, later, be built from a special
table-gen back-end that will always be enabled for all targets, but
that's much later.

The final goal is to keep all that information into one big
TargetDescription class, which will also help Clang and other users to
know information about the targets, for instance, what combination of
environment, ABI and CPU features, to take informed decisions without
needing any back-end built in.

Is that in line with your reasoning?

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Daniel Sanders
> From: Renato Golin [[hidden email]]
> Sent: 26 May 2015 18:43
> To: Daniel Sanders
> Cc: Jim Grosbach; LLVM Developers Mailing List ([hidden email])
> Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
>
> On 26 May 2015 at 14:58, Daniel Sanders <[hidden email]> wrote:
> > The intention isn't to change the kind of triples/tuples in use by toolchains and
> > users. There's a lot of legacy and inertia to overcome if we try that. The intention
> > is to map the ambiguous/insufficient GNU triples onto an internal representation
> > as early as possible and pass that internal representation throughout LLVM and
> > the LLVM-IR files. The end-users can still use GNU triples and compiler options
> > such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM
> > tuple.
>
> Ok, so that will probably involve the Triple / Parser refactoring I'm doing.
>
> Right now, Triple handles some of that, but it's not authoritative not
> final. I've created an ARMTargetParser class that deals with parsing
> arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM
> is done already) to it. We may also have to move llc, lli and others.
>
> Once this is done, we can begin to move more logic to the Triple in
> the same way, and let target specific Triple management in their own
> classes (like ARMTargetParser), so that Clang doesn't need all
> back-ends to have all arch knowledge. This way, the Triple class will
> be able to take any architecture-specific decision with just strings.
> Such arch-specific classes will, later, be built from a special
> table-gen back-end that will always be enabled for all targets, but
> that's much later.
>
> The final goal is to keep all that information into one big
> TargetDescription class, which will also help Clang and other users to
> know information about the targets, for instance, what combination of
> environment, ABI and CPU features, to take informed decisions without
> needing any back-end built in.
>
> Is that in line with your reasoning?
>
> cheers,
> --renato

Yes, that sounds quite similar to what I'm thinking. The LLVM Tuple concept is essentially your TargetDescription class. I wasn't planning on going as far as ARMTargetParser does since my focus is on the LLVM internals but it makes sense to me and fits nicely with the idea of mutating the LLVM Tuple in response to compiler options.

The steps I'm thinking of for the GNU triple to LLVM Tuple migration are:
* Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.
* Split the Triple class into Triple and LLVMTuple classes. Both are identical in implementation at this stage except that Triple has a 'getLLVMTuple()' member function.
* Gradually replace Triple's with LLVMTuple's until the public APIs are the only place Triple's are still used.
* Change the internals of LLVMTuple to whatever is convenient.
* Add public API's that use LLVMTuple's and migrate API users (clang, llc, lli, etc.) to the new API.
* Have the API users mutate the LLVMTuple appropriately.

Maybe we can merge our plans and attack it from both directions at the same time.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

Renato Golin-2
On 27 May 2015 at 22:44, Daniel Sanders <[hidden email]> wrote:
> Yes, that sounds quite similar to what I'm thinking. The LLVM Tuple concept is essentially your TargetDescription class. I wasn't planning on going as far as ARMTargetParser does since my focus is on the LLVM internals but it makes sense to me and fits nicely with the idea of mutating the LLVM Tuple in response to compiler options.

Perfect. This would be my next step, but since you're covering, I
think we can split the work nicely.

My focus now is in restricting the parsing of strings to a single
place. Most architectures are very simple, so a generic TargetParser
would do. But ARM is a huge mess of names and synonyms, so I need a
specialised class.

My final goal is to have your Tuple class handle everything, using my
TargetParser class to initialise the object from strings (like Triple
does) and to validate further changes to the internal state via option
strings, either from the command line, assembly files, etc.

There is a lot of string handling in Clang for options in static
functions all over the place. I'm replacing all ARM ones for
ARMTargetParser calls. This would make easy for you to spot places
where you should add the new Tuple class.

Right now, my parser is just a static class with helper methods, but
once we start having more than one target, we'll need to derive it
from a generic TargetParser, and make it an integral part of the Tuple
class.

Some comments...


> * Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.

Part of that is done already, with Triple having several enums to hold
the values. But many of those enums are incomplete, especially in the
ARM side. My TargetParser enums are, so far, complete and correct. We
should definitely merge them, though I'll leave it for you to decide
whether to leave it in the parser, or to make the parser depend on the
tuple's enums, or to have a third include file.

Remember that those enums and tables will have to be generated from a
table-gen backend, that will be executed on every build, even if no
targets are built in.


> * Split the Triple class into Triple and LLVMTuple classes. Both are identical in implementation at this stage except that Triple has a 'getLLVMTuple()' member function.

I'd call it TargetTuple, not LLVMTuple. :)


> * Gradually replace Triple's with LLVMTuple's until the public APIs are the only place Triple's are still used.
> * Change the internals of LLVMTuple to whatever is convenient.
> * Add public API's that use LLVMTuple's and migrate API users (clang, llc, lli, etc.) to the new API.
> * Have the API users mutate the LLVMTuple appropriately.

Sounds like a plan. And one that we can reach each other in the middle
ground in time. I think we can continue with our original plans, and
re-group once we reach it.

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev