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@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
