[llvm-dev] Inlining with different target features

[Eric Christopher via llvm-dev]

Hi Thomas,

I'd prefer not to change areInlineCompatible because I think it reads
fairly closely what is expected here (also see x86 for how this is used for
subset inlining calculations). I think if you plan on updating all of the
features for the functions to match you might just want to do that
initially rather than try to update them piecemeal after or during
inlining.

Thoughts?

-eric

On Mon, Aug 17, 2020 at 4: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/b83de0fd/attachment.html>