[llvm-commits] [llvm-gcc-4.0] r41882 - in /llvm-gcc-4.0/trunk/gcc: config/darwin.h llvm-backend.cpp varasm.c

[Chris Lattner]

On Sep 17, 2007, at 3:35 PM, Bill Wendling wrote:

>> Instead, I suggest we output a warning in the f-e that aliases are  
>> not supported,
>> but still generate the alias in the bitcode.  Then we teach the  
>> code generators,
>> which presumably means the asm printer, to ignore aliases on Darwin

Will this really work?  If the optimizer sees aliases, it could  
presumably do something with them, potentially adding dependencies on  
them being handled "right".

If nothing else, the alias that will eventually not get emitted can  
cause symbol table clashes as link stages are done.

I don't think it's a good idea for targets that don't support aliases  
to have aliases in their module.

>>
>> On the other hand, not all bitcode is generated by llvm-gcc.  It  
>> may be a bad
>> idea to have LLVM quietly ignore aliases on Darwin because of the  
>> potential
>> surprise and trouble it may create for front-end writers who  
>> aren't aware of
>> this.
>>
> Good point. As Evan points out, the asm printer is already doing a lot
> of stuff that it shouldn't, but my patch doesn't handle the case where
> bitcode is generated by non-llvm-gcc programs or on other platforms.
> :-/ I'll check into this more. The macro can stay and we can just emit
> the warning, still emit the global aliasing code, but ignore it during
> assembly emission.
>
> Evan, does this sound like an okay idea?

I think it is reasonable for the target to tolerate and ignore  
aliases if it sees them and they aren't supported, but I think this  
is an area where a front-end needs to be "target aware".  Maybe  
TargetAsmInfo (which is used by the front-end) should have a bool  
indicating whether aliases are supported, and maybe we should use  
that to control llvm-gcc instead of the GCC macro?

-Chris