[PATCH] D109888: Bitcast wrapped in a call obscures function attributes, pessimizing MemorySSA
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 16 12:13:20 PDT 2021
jdoerfert added a comment.
In D109888#3004544 <https://reviews.llvm.org/D109888#3004544>, @nikic wrote:
> I'm okay with this for the case of function attributes in particular, because those don't really depend on ABI considerations. I will say though that you're brushing really close to UB here, and I may push back against extending other places in this direction. Like, say you have a `void(i128)` and call it as `void(i64, i64)` knowing that under the particular ABI used those two i64s will assemble into an i128 -- is that a legal call? In what manner would a function param attribute correlate with call arguments there?
I second this.
Recently I (had to) start to fix all the places in the Attributor that are not aware that call site and callee might mismatch wrt. parameters (due to casts). It's a mess even w/o attributes.
For functions we should be OK because there is no ambiguity what the "function" is.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109888/new/
https://reviews.llvm.org/D109888
More information about the llvm-commits
mailing list