[llvm-dev] Inlining with different target features

[David Blaikie via llvm-dev]

+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/6f5894ee/attachment.html>