This is an archive of the discontinued LLVM Phabricator instance.

[CallPromotion] Fix byval/inalloca handling
AbandonedPublic

Authored by aeubanks on Aug 9 2021, 9:49 AM.

Details

Reviewers
rnk
wmi
Summary

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.

Diff Detail

Event Timeline

aeubanks created this revision.Aug 9 2021, 9:49 AM
aeubanks requested review of this revision.Aug 9 2021, 9:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2021, 9:49 AM

the alternative is to not allow promotion to a call with differing ABI attributes

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.

aeubanks abandoned this revision.Aug 12 2021, 2:35 PM

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.

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.
https://reviews.llvm.org/D107998