[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 1:59 AM, Duncan Sands wrote:

> Hi Bill,
>
>>>> Alias definitions aren't supported on some platforms. Create a
>>>> flag (TARGET_DOES_NOT_SUPPORT_ALIAS_DEFINITIONS) that indicates
>>>> this and stops us from creating aliases.
>>>
>>> is doing this in the front-end really the right approach?  If a
>>> target doesn't
>>> support aliases surely it is LLVM codegen that should complain or
>>> ignore the
>>> alias.
>>
>> It's debatable. I'm not 100% familiar with the "emit_alias_to_llvm()"
>> function, but it seems to be modifying the generated LLVM bitcode to
>> point to the new alias.
>
> I've CC'd Anton since he's the one who knows all about this stuff.   
> Presumably

Anton CC'd.

>
> 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.

Hmm. I thought "weak alias" just means "weak" and "alias". It's a  
different animal from weakref (which Darwin supports).

> 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.

I don't think Bill's patch affects weakref. Bill?

>
>
> 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.

We are already relying on asm printer too much as it is. I'd like not  
to add any more target specific knowledge to asm printer if possible.

Evan

>
>
> 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.
>
>> If so, then we need to stop it from doing
>> that at that point, which is what my patch does.
>>
>> Also, I don't think there's anything that emits a warning in LLVM
>> after the front-end generates the bitcode. I'm not excited about
>> emitting warnings there now. :-)
>>
>>> Also, how does gcc handle aliases on Darwin?  Either it succeeds in
>>> outputting them somehow, in which case llvm-gcc should too, or it
>>> rejects them
>>> in which case there shouldn't be any need for a new flag - the info
>>> that darwin
>>> doesn't support aliases should exist in gcc already.
>>>
>> GCC ignores it. If you look at config/darwin.h, it emits a warning
>> saying that it won't be doing anything with aliases.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits