[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