On Sep 17, 2007, at 3:35 PM, Bill Wendling wrote: >> 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
Will this really work? If the optimizer sees aliases, it could presumably do something with them, potentially adding dependencies on them being handled "right". If nothing else, the alias that will eventually not get emitted can cause symbol table clashes as link stages are done. I don't think it's a good idea for targets that don't support aliases to have aliases in their module. >> >> 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 think it is reasonable for the target to tolerate and ignore aliases if it sees them and they aren't supported, but I think this is an area where a front-end needs to be "target aware". Maybe TargetAsmInfo (which is used by the front-end) should have a bool indicating whether aliases are supported, and maybe we should use that to control llvm-gcc instead of the GCC macro? -Chris _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
