https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124420
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #2)
> (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.
Alternatively the above could be made cgraph edge specific given POLY_INT_CSTs
are invariant within sub-call-graphs. It might be possibly nice to have
a more explicit representation of such sub-graphs, we have similar for
target/optimization option node annotated functions where inlining isn't
possible (and that's a directional thing there even).
Note I didn't check whether excluding POLY_INT_CSTs from being
ip invariant is enough to fix the observed issue.
It's also that probably explicit POLY_INT_CST passing doesn't happen often?
How does this affect VECTOR_CST of VLA vector types passing? I suppose
the representation could become invalid?
