This is an archive of the discontinued LLVM Phabricator instance.

[ArgPromotion][TTI] Pass types to ABI compatibility hook
ClosedPublic

Authored by nikic on Dec 20 2021, 5:17 AM.

Details

Summary

The areFunctionArgsABICompatible() hook currently accepts a list of pointer arguments, though what we're actually interested in is the ABI compatibility after these pointer arguments have been converted into value arguments.

This means that a) the current API is incompatible with opaque pointers (because it requires inspection of pointee types) and b) it can only be used in the specific context of ArgPromotion. I would like to reuse the API when inspecting calls during inlining.

This patch converts it into an areTypesABICompatible() hook, which accepts a list of types. This makes the method more generally usable, and compatible with opaque pointers from an API perspective (the actual usage in ArgPromotion/Attributor is still incompatible, I'll follow up on that in a separate patch).

Diff Detail

Event Timeline

nikic created this revision.Dec 20 2021, 5:17 AM
nikic requested review of this revision.Dec 20 2021, 5:17 AM
Herald added a reviewer: sstefan1. · View Herald Transcript
Herald added a reviewer: baziotis. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
dblaikie accepted this revision.Dec 21 2021, 9:33 AM
dblaikie added a subscriber: dblaikie.

Sounds OK. Another possibility might be splitting the operations - one to test function compatibility (eg: the subtarget AVX checks in x86) and another to test a particular arg/return type. This would mean more virtual calls (one for each type instead of a batch - well, the API could still take ArrayRef for cases where you already have multiple types in a buffer) but wouldn't require allocating a new buffer to fill with types to then pass in? But maybe the number's usually low, so the buffer creation overhead isn't high?

This revision is now accepted and ready to land.Dec 21 2021, 9:33 AM

Sounds OK. Another possibility might be splitting the operations - one to test function compatibility (eg: the subtarget AVX checks in x86) and another to test a particular arg/return type. This would mean more virtual calls (one for each type instead of a batch - well, the API could still take ArrayRef for cases where you already have multiple types in a buffer) but wouldn't require allocating a new buffer to fill with types to then pass in? But maybe the number's usually low, so the buffer creation overhead isn't high?

I think generally the check for target features and types does need to be combined, because the specific difference in target attributes decides whether the call ABI for a particular type changes or not. None of our existing implementations actually try to model things that precisely, but from a conceptual point of view these are interdependent. In any case, I don't think compile-time really matters for this API.

Sounds OK. Another possibility might be splitting the operations - one to test function compatibility (eg: the subtarget AVX checks in x86) and another to test a particular arg/return type. This would mean more virtual calls (one for each type instead of a batch - well, the API could still take ArrayRef for cases where you already have multiple types in a buffer) but wouldn't require allocating a new buffer to fill with types to then pass in? But maybe the number's usually low, so the buffer creation overhead isn't high?

I think generally the check for target features and types does need to be combined, because the specific difference in target attributes decides whether the call ABI for a particular type changes or not. None of our existing implementations actually try to model things that precisely, but from a conceptual point of view these are interdependent. In any case, I don't think compile-time really matters for this API.

Ah, sounds good!

This revision was landed with ongoing or failed builds.Dec 22 2021, 12:38 AM
This revision was automatically updated to reflect the committed changes.