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

[Evan Cheng]

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

> Hi Duncan (et al),
>
>> I've CC'd Anton since he's the one who knows all about this stuff.   
>> Presumably
>> when A is an alias for B there are two cases: either this is a  
>> "weak alias" or
>> weakref, meaning that at link time it may turn out that A wasn't an  
>> alias for
>> B after all, or A is a strong alias (a term I just invented) for B,  
>> meaning that
>> this is definitive: you can replace uses of A with uses of B  
>> everywhere.  In the
>> first case linker support is required, but not in the second case,  
>> so presumably
>> it is wrong to turn off alias support in the second case.  I don't  
>> know if your
>> patch turned this second case off or not.
>>
>> In the first case (weakrefs) we output a special declaration to the  
>> bitcode
>> saying that A is a weak alias for B.  I think it is a mistake not  
>> to output
>> this even for platforms like Darwin that don't handle weakrefs:  
>> such aliases
>> may be resolvable by LLVM, for example when linking modules using  
>> llvm-link.
>> Think also of running bitcode under lli.  Thus there are some cases  
>> in which
>> weakrefs can work correctly even on Darwin.
>>
>> 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.
>>
>> 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 don't really see a clean solution at this point. I guess asm printer  
will have to handle bitcode generated for a different target. :-(

Evan

>
>
> -bw
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits