llvm dev - May 2015 - [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo

> 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:rnk at google.com]
Sent: 22 May 2015 16:22
To: Daniel Sanders
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
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 <Daniel.Sanders at
imgtec.com<mailto:Daniel.Sanders at imgtec.com>> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.imgtec.com_&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=zfZRQGD_5uNPepX1eAkaBGbEPGddM5b_p16e7gchhmA&s=jcHeVUlAAMi_-CIYlWvRUYcfRKFShMSHzLBBZFz7FYI&e=>


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/af138242/attachment.html>

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 <Daniel.Sanders at
imgtec.com> 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
<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 [mailto:rnk at google.com] 
> Sent: 22 May 2015 16:22
> To: Daniel Sanders
> Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> 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 <Daniel.Sanders at
imgtec.com <mailto:Daniel.Sanders at imgtec.com>> 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
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.imgtec.com_&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=zfZRQGD_5uNPepX1eAkaBGbEPGddM5b_p16e7gchhmA&s=jcHeVUlAAMi_-CIYlWvRUYcfRKFShMSHzLBBZFz7FYI&e=>
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/f85a82e2/attachment.html>

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com>
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