[llvm-dev] Inlining with different target features

[David Blaikie via llvm-dev]

On Mon, Aug 31, 2020 at 1:23 PM Thomas Lively <tlively at google.com> wrote:

> Thanks for your reply! Using module metadata is an interesting idea, but
> it would require frontends to make wasm-specific changes to how they handle
> target features, which would be unfortunate. Working around that by
> extracting target features into metadata somewhere seems like it would be
> at least as intrusive as having the inliner update target features. We
> would also lose out on other valuable utilities like the ability to limit
> target intrinsics to certain features.
>

Fair enough all round. Though how does wasm work with this "spread the
features all around" - does the resulting binary end up only being
compatible with a target that has those features? Essentially making
features impossible to use conditionally? (I couldn't write some code that
did a runtime test for certain features, then used them only under that
condition - because my whole program would end up with the features enabled
anyway?)

Another direction would be to require the features to be specified
consistently for all components of the build, I guess - if that's the net
effect anyway. Would make portable libraries difficult, though - because
they'd be linked into different things with different feature sets and that
would violate the invariant.


>
> On Mon, Aug 31, 2020 at 9:52 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> +echristo for thoughts on subtarget features and function inlining.
>>
>> Maybe target features aren't the right tool to model the WebAssembly
>> situation? Perhaps you could model those with mergeable module-level
>> metadata instead? Then the module would always have all the features and
>> that would match the "we're allowed to union all features across all
>> functions anyway" without it being a delayed pass that happens later.
>>
>> On Mon, Aug 17, 2020 at 1:49 PM Thomas Lively via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi llvm-dev,
>>>
>>> I recently updated the WebAssembly TargetTransformInfo to allow
>>> functions with different target feature sets to be inlined into each other,
>>> but I ran into an issue I want to get the community's opinion on.
>>>
>>> Since WebAssembly modules have to be validated before they are run, it
>>> only makes sense to talk about WebAssembly features at module granularity
>>> rather than function granularity. The WebAssembly backend even runs a pass
>>> that applies the union of all used features to each function. That means
>>> that ideally inlining for the WebAssembly target would be able to disregard
>>> features entirely, since they will all be the same in the end.
>>>
>>> However, right now I have to be more conservative than that and only
>>> allow a callee to be inlined into a caller if the callee has a subset of
>>> the caller's features. Otherwise, a target intrinsic might end up being
>>> used in a function that does not have the necessary target features
>>> enabled, which would cause a validation failure.
>>>
>>> The best solution I can think of for this problem would be to allow
>>> targets to opt-in to having a caller's feature set updated to include the
>>> callee's feature set when the callee is inlined into the caller. This could
>>> be implemented via a new TTI hook, but a more general solution might be to
>>> change the return type of `areInlineCompatible` to allow targets to control
>>> this behavior on a case-by-case basis. Does this general direction sound
>>> ok, and if so, would it be better to add a new hook or add functionality to
>>> the existing one?
>>>
>>> Thanks,
>>>
>>> Thomas
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200831/c00db50e/attachment.html>