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

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<http://www.imgtec.com/>

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

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 <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         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/9461d025/attachment.html>

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>
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         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/29405c10/attachment.html>

> 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>