[PATCH] D111403: [Inliner] Don't inline functions with incompatible vscale_range attributes
David Sherwood via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 11 04:00:01 PDT 2021
david-arm added inline comments.
================
Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1800
+ // don't match.
+ if (!CallerMinVScale || !CallerMaxVScale || !CalleeMinVScale ||
+ !CalleeMaxVScale)
----------------
sdesmalen wrote:
> Currently this code would avoid inlining a function with
>
> `vscale_range(0, 16)` into a function with `vscale_range(4, 16)`
>
> which we should probably allow.
>
> For the 'unbounded' minimum I think we can interpret this as '1' (i.e. the minimally required vscale could be anything, it means it (also) has to run on a vscale of 1, so we can assume 1).
> For the unbounded maximum we can interpret this as UINT_MAX (i.e. the length of the vector is unknown, so assume worst-case)
>
> And then do the individual comparisons on those newly interpreted values.
I wonder what the point is of having a 0 for the minimum here then? It feels like we should just never allow a 0 minimum for vscale_range as I don't think the LangRef is particularly clear. The way I read the LangRef it sounds like min could be anything, like 8 or 3. If min could be >4 then it's not safe to inline, right? At the moment it feels like we're tightening the meaning of the vscale_range attribute without changing the documentation, which feels a bit dangerous that's all.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D111403/new/
https://reviews.llvm.org/D111403
More information about the llvm-commits
mailing list