llvm dev - Nov 2010 - [LLVMdev] Build Attributes Proposal

> Hi Duncan,
>
> This could work, but it's very limited. Besides, there's already an
MC
> build attribute infrastructure, one would have to interpret those
> strings in the back-end to an MC construct then back again to ASM and
> ELF.
>
> I don't see why having a magic global would be worse than using module
asm...
So, you mentioned that there should be no attributes that were not
requested by the users, right? If that is so, can't you produce the
asm in clang or you FE and have llvm never introduce new ones? LLVM
itself doesn't use the attributes, so it doesn't need to interpret
them.
> --renato
Cheers,
Rafael

On Nov 17, 2010, at 2:55 PM, Rafael Espíndola wrote:
>> Hi Duncan,
>> 
>> This could work, but it's very limited. Besides, there's
already an MC
>> build attribute infrastructure, one would have to interpret those
>> strings in the back-end to an MC construct then back again to ASM and
>> ELF.
>> 
>> I don't see why having a magic global would be worse than using
module asm...
> 
> So, you mentioned that there should be no attributes that were not
> requested by the users, right? If that is so, can't you produce the
> asm in clang or you FE and have llvm never introduce new ones? LLVM
> itself doesn't use the attributes, so it doesn't need to interpret
> them.
Right, we do similar things for Objective-C metadata that there is no reason to
represent in IR, the objc frontend (like clang) just produces module-level
inline assembly blobs.

-Chris

2010/11/17 Rafael Espíndola <rafael.espindola at
gmail.com>:
>> Hi Duncan,
>>
>> This could work, but it's very limited. Besides, there's
already an MC
>> build attribute infrastructure, one would have to interpret those
>> strings in the back-end to an MC construct then back again to ASM and
>> ELF.
>>
>> I don't see why having a magic global would be worse than using
module asm...
>
> So, you mentioned that there should be no attributes that were not
> requested by the users, right? If that is so, can't you produce the
> asm in clang or you FE and have llvm never introduce new ones? LLVM
> itself doesn't use the attributes, so it doesn't need to interpret
> them.
Another use for build attributes would be as a means to record the
build flags selected for each translation unit so that LTO could know
how to optimize/tune the result. This use seems more important to
solve than the ARM attributes under discussion here.

deep

> Another use for build attributes would be as a means to record the
> build flags selected for each translation unit so that LTO could know
> how to optimize/tune the result. This use seems more important to
> solve than the ARM attributes under discussion here.
If needed, these attributes should be per function, no? How do you
handle "ld -r" ?
> deep
>
Cheers,
Rafael

Forgot to reply all to include the list.

deep

---------- Forwarded message ----------
From: Sandeep Patel <deeppatel1987 at gmail.com>
Date: 2010/11/17
Subject: Re: [LLVMdev] Build Attributes Proposal
To: Rafael Espíndola <rafael.espindola at gmail.com>


2010/11/17 Rafael Espíndola <rafael.espindola at
gmail.com>:
>> Another use for build attributes would be as a means to record the
>> build flags selected for each translation unit so that LTO could know
>> how to optimize/tune the result. This use seems more important to
>> solve than the ARM attributes under discussion here.
>
> If needed, these attributes should be per function, no? How do you
> handle "ld -r" ?
I suppose per-function is best. I'd argue that the ARM attributes are
all per-function as well. My favorite example is
__attribute__((pcs("aapcs-vfp"))) as a function attribute to select
the calling convention.

Maybe these attributes could referenced like metadata so they can be
merged if identical?

deep

On 17 November 2010 23:13, Sandeep Patel <deeppatel1987 at gmail.com>
wrote:
> I suppose per-function is best. I'd argue that the ARM attributes are
> all per-function as well. My favorite example is
> __attribute__((pcs("aapcs-vfp"))) as a function attribute to
select
> the calling convention.
>
> Maybe these attributes could referenced like metadata so they can be
> merged if identical?
LLVM IR already represents that as aapcs_vfpcc function attribute.

cheers,
--renato

2010/11/17 Rafael Espíndola <rafael.espindola at
gmail.com>:
> So, you mentioned that there should be no attributes that were not
> requested by the users, right? If that is so, can't you produce the
> asm in clang or you FE and have llvm never introduce new ones? LLVM
> itself doesn't use the attributes, so it doesn't need to interpret
> them.
This comment is a bit misleading...

First, The user chooses the cpu, fpu, calling convention,
floating-point optimizations, instruction sets, etc. Most of it is
encoded in the target triple (ex: thumbv6m), others in command-line
options (-mcpu, -mfpu, etc). Based on that fact, yes, the build
attributes are always requested by the user, but that's not the whole
story. The user can request incompatible attributes (like thumbv4), so
the compiler as to warn or stop. Some attributes in one object can be
incompatible with another object, and it's up to the linker to
recognized that, merge if possible or bail out otherwise. There is
room for guessing, but the idea of the build attributes are precisely
to reduce that guessing game as much as possible to force errors in
compile time rather than run time.

Second, as you know, build attributes are not exclusively assembly
tags, they have to be printed to ELF as well, and the ARM ELF back-end
will have to get that information somewhere. The best part of this
information will come from SubTarget, as we discussed before, but some
restrictions must come from somewhere else. So the LLVM back-end must
interpret them when they come, and parsing asm is not the way I'd do
it.

However, depending on how you compile using LLVM, you might not need
it in the IR. The reason is that the command-line options can be
passed straight through ASM/ELF if you compile using some driver
(clang, llvm-gcc). But that won't work if you compile to BC, than
compile to ASM/ELF later. My personal opinion is that, independent on
how you compile your file, the result should be the same. So, having
build attributes in the IR is the only choice.

One could argue that it's not necessary, the docs could cover that
easily and we wouldn't have to add an extra complexity to the IR.
Based on how Clang parameters for target triple work today (-ccc
against -cc1 ...), I guess that decision was taken before, so that
wouldn't be a first. But that's obviously not my call.

I could go over the build attributes list to name a few important
ones, but there're two that comes to my mind: ARM/Thumb
interoperability and FP optimization level (IEEE, fast), both
important for choosing the right libraries/calls at link time. I don't
believe there is any other way of representing them in IR today... But
I could be wrong, obviously...

best,
--renato

Hi Sandeep,
> Another use for build attributes would be as a means to record the
> build flags selected for each translation unit so that LTO could know
> how to optimize/tune the result. This use seems more important to
> solve than the ARM attributes under discussion here.
why not have your build system just pass the appropriate flags directly to the
linker?  Also, suppose some files were compiled at -O1, others at -O3.  If you
do LTO then these files will all be linked together and optimized, but at what
-O level?  I think it would be wrong to have the linker make policy decisions
like "optimize at the highest -O level seen" or "optimize at the
lowest -O level
seen".  Better to have the user explicitly say what they want.  But in that
case
is there any need to record the -O level in some special way in the module in
the first place?

Ciao,

Duncan.