https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124420
--- Comment #2 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I guess we need sth similar to the can_inline_p hook. But I also thought
> that there's globally a single factor determining the actual POLY_INT_CST
> constant.
That was the initial assumption, but...
> So that's no longer the case and POLY_INT_CSTs are not IP invariant?
...that's right. There was always the risk that we might have needed to relax
it if we provided a defined way of changing the SVE (i.e. non-streaming) VL.
But that would have required explicit function markup, similar to what we now
have for SME.
> IMO one bug then is that svcntd() exposes a POLY_INT_CST instead of
> evaluating it.
The idea was that we'd treat locally-streaming functions as having SME VL up
until pass_late_thread_prologue_and_epilogue, after which point no code motion,
propagation, CSE, etc, would be allowed. So I think this lowering is ok. But:
> /* Return true if T is a GIMPLE minimal invariant. It's a restricted
> form of function invariant. */
>
> bool
> is_gimple_min_invariant (const_tree t)
> {
> if (TREE_CODE (t) == ADDR_EXPR)
> return is_gimple_invariant_address (t);
>
> return is_gimple_constant (t);
> }
>
> /* Return true if T is a GIMPLE interprocedural invariant. It's a restricted
> form of gimple minimal invariant. */
>
> bool
> is_gimple_ip_invariant (const_tree t)
> {
> if (TREE_CODE (t) == ADDR_EXPR)
> return is_gimple_ip_invariant_address (t);
>
> return is_gimple_constant (t);
> }
>
> so POLY_INT_CSTs are not is_gimple_ip_invariant?
Ah, yeah. I suppose is_gimple_ip_invariant ought to return false now that SME
exists. I don't know whether that would pessimise RISC-V (and so need a
hook/macro) or whether it could be unconditional.
