[LLVMdev] Build Attributes Proposal

[Duncan Sands]

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.