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

Bill Wendling isanbard at gmail.com
Mon Sep 17 15:35:16 PDT 2007


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?

-bw



More information about the llvm-commits mailing list