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

[Duncan Sands]

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

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