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

Hi Renato,
> On 13 November 2010 10:06, Duncan Sands<baldrick at free.fr>  wrote:
>>    module asm "\09.ident\09\22GCC: (GNU) 4.5.2 20101028
(prerelease) LLVM:
>> 118890\22"
>
> 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 agree that it's limited.  As for MC, it will need to handle these strings
anyway since this is an existing LLVM feature (coming from gcc originally)
that needs to be supported.
> I don't see why having a magic global would be worse than using module
asm...
Because magic globals need magic treatment, i.e. special logic in the code
generators etc.  Why add all this new stuff if an existing feature will do?

Ciao,

Duncan.

On 13 November 2010 15:12, Duncan Sands <baldrick at free.fr>
wrote:
> I agree that it's limited.  As for MC, it will need to handle these
strings
> anyway since this is an existing LLVM feature (coming from gcc originally)
> that needs to be supported.
Do you mean that LLVM-GCC generates build attributes as asm strings in IR?

> Because magic globals need magic treatment, i.e. special logic in the code
> generators etc.  Why add all this new stuff if an existing feature will do?
Build attributes are not asm specific, and implementing them in an asm
specific keyword seems kludge to me. Not to mention that you lock the
IR in a ARM-GNU-ASM specific mode, which is a dead-end. Also, passing
".build_attribute" strings in IR if you're producing ELF
doesn't make
sense, IMO.

In a global array, the indexes are represented directly, only leaving
the associated string if additional information is necessary (like CPU
name, which is already a string).

cheers,
--renato

Hi Renato,
> On 13 November 2010 15:12, Duncan Sands<baldrick at free.fr>  wrote:
>> I agree that it's limited.  As for MC, it will need to handle these
strings
>> anyway since this is an existing LLVM feature (coming from gcc
originally)
>> that needs to be supported.
>
> Do you mean that LLVM-GCC generates build attributes as asm strings in IR?
no, I mean that gcc supports file level ASM, which is why llvm-gcc and LLVM
support it too, and which presumably means that MC will have to support it
one day.
>> Because magic globals need magic treatment, i.e. special logic in the
code
>> generators etc.  Why add all this new stuff if an existing feature will
do?
>
> Build attributes are not asm specific, and implementing them in an asm
> specific keyword seems kludge to me. Not to mention that you lock the
> IR in a ARM-GNU-ASM specific mode, which is a dead-end. Also, passing
> ".build_attribute" strings in IR if you're producing ELF
doesn't make
> sense, IMO.
It is hard for me to comment because I don't know anything about these
attributes.  However, presumably they need to end up in the .s file.
I'm pointing out that you can put anything you like into the assembler
via module level asm.  I'm not sure what you mean by "build attributes
are not asm specific".  I never suggested they were!  The so-called asm
is just a directive saying: place this string as-is in the final assembler.
I'm also not sure what ELF has to do with anything.
> In a global array, the indexes are represented directly, only leaving
> the associated string if additional information is necessary (like CPU
> name, which is already a string).
Since I don't know anything about these attributes, talk of indexes and
so forth goes straight over my head.

All I'm saying is that if you want a series of strings to end up in the
.s file, this can be done using an existing LLVM feature.

Ciao,

Duncan.