[llvm] r181753 - This is the first of three patches which creates stubs used for

[reed kotler]

On 05/15/2013 07:14 AM, Rafael Espíndola wrote:
>> I probably air too much of what I'm doing on the list as far as design and
>> my attempt is never to hide such things. I really could not have imagined
>> such a big discussion about generating some tiny stubs . It only came up
>> during the issue of the APP/NO_APP wrappers.
> I still think you are doing this wrong and it will be harder to
> implement it correctly once you have this in. IMHO the only thing
> needing special treatment for the stubs in the backend would be
> calling convention. Other than that they would be regular mips16 or
> mips32 *IL* functions. Mixing mips16 and mip32 should not be that
> different from mixing thumb and arm.
This is a separate module pass. There is nothing being done here except 
solving this problem
so it's easy to modify, delete or replace in the future..

I have filed a bug already against myself at Mips to look at this issue 
of using special calling conventions. I did a special calling convention 
already for the return helpers but these are more involved. There are 
special issues here not normally covered by a simple calling convention. 
If you look at the code in assureFPCallStub you will see that the way 
the helper even calls the real function depends on whether the function 
returns float, double, single or double complex and then the final 
return is different too. The next patch after this, which you have not 
seen yet, relies on some special gas tricks that. This is just the way 
it was designed for gcc but it's very efficient the way they work
so that was the reason.

I'm with you on making things better and simpler all the time. It's not 
always practical to hit the
final goal on the first try.


> But you are correct, I don't have big objections to you guys
> implementing this in the way you think is best, *as long as it stays
> local to mips*. In particular, two things that came up in this
> discussion that really don't want to see in trunk are:
>
> * the ability for the compiler to tell if an inline asm is compiler
> generated or human written. (the APP/NO_APP discussion). I am ok with
> avoiding printing them, as long as we avoid for all inline asm (by not
> printing it at all for mips target for example).
This APP/NO_APP would be covered in a separate patch and is only for 
cosmetic purposes.

I was not asking for the compiler to be able to tell this.

I want be able to have a function attribute which tells asmprinter to 
not emit those.
This could be usable by the compiler itself or if we *chose* to make it 
general, by a user.

When GCC creates these stubs, they look like normal compiler code (no 
APP/NO_APP) markers
and without this ability LLVM is going to add these markers after each line.

There is no functional difference in the code but they look ugly to me 
and it makes it harder to
read them.

This is not really that important but I think we should not have them 
here because they serve no
purpose other than to make the stub harder to read.
> * the extension of the section attribute to be an arbitrary string
> passed to the assembler or the addition of section related attributes
> (i.e., llvm.org/pr15788 should be closed as wontfix).
I did not need anything special here as I thought I would originally.
I was able to use the builtin function attributes that LLVM supports to 
get the desired result.


Thanks for taking the time to respond in such detail.

Reed

> Cheers,
> Rafael