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