erichkeane added a comment. In D158666#4611494 <https://reviews.llvm.org/D158666#4611494>, @eandrews wrote:
> In D158666#4611481 <https://reviews.llvm.org/D158666#4611481>, @erichkeane > wrote: > >> I think the .ifunc spelling was an oversight on my part when I implemented >> this, I didn't spend enough time investigating GCC's behavior when >> implementing this feature. I think the alias is the right way about it, but >> I think the .ifunc should be the alias (at least as far as I can think it >> through right now). I think that works better because it supports a case >> where the 'definition' of the target-clones function is generated with GCC, >> but the 'caller' (also with target clones) comes from clang. I THINK that >> makes more sense? But perhaps try to chart out the behavior of the GCC/Clang >> "Knows about TC"/"Doesn't know about TC" in each situation to see which are >> troublesome? >> >> Additionally, this needs a release note. > > Thanks for taking a look! Can you explain why we need an alias? As in, if we > just remove the .ifunc suffix in the 'ifunc' function here, it should work > without an alias I think. I have to re-check but IIRC this is what GCC does At least short term, we have to have both .ifunc and <just function name> exposed, else we end up breaking SOMEONE. At the moment, we're breaking the example you have, however if we just switch the .ifunc to be <function name>, we end up breaking cases where 1 TU is built with Clang 18 and the other with Clang-trunk. So we need to figure out what the 'compatibility story' is between Clang 18, Clang-Trunk, and GCC with each of them in the position of: 1- Generated the function TU 2- Consumed the function, not knowing about it being TC 3- Consumed the function, knowing it was TC. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158666/new/ https://reviews.llvm.org/D158666 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
