If the previously indirect call contained a byval/inalloca attribute but
the callee did not have the same attribute, we'd end up not updating the
call's type attribute.
Followup to D63842.
Fixes PR51397.
Differential D107770
[CallPromotion] Fix byval/inalloca handling aeubanks on Aug 9 2021, 9:49 AM. Authored by
Details
Diff Detail
Event TimelineComment Actions I'd prefer to prohibit the promotion. In general, when we see a mismatch in the argument list, we want to be conservative; ABI rules are complicated, so sometimes different frontends will emit different IR signatures for a given function which should be ABI-compatible. An argument list with byval is effectively a different signature from an argument list without byval. Comment Actions If we do indirect call promotion guarded by checking the function addresses, it should be fine in terms of correctness, we'd just presumably never do the direct call. I was trying to preserve the current state of allowing ABI-incompatible indirect call promotion. But we might as well just do what you said. |