https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124420
--- Comment #4 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Richard Biener from comment #3) > 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). Sounds good. (But a lot of work...) > It's also that probably explicit POLY_INT_CST passing doesn't happen often? Not sure it's that rare. We have vector libm routines, and it would be natural to pass vectors to some SME subroutines. But the spec has verbiage to say that passing POLY_INT_CST vectors across mode changes is UB unless the streaming and non-streaming VLs are equal [https://github.com/ARM-software/acle/blob/main/main/acle.md#calling-restrictions-related-to-streaming-mode]. > How does this affect VECTOR_CST of VLA vector types passing? I suppose > the representation could become invalid? VECTOR_CSTs are hopefully ok, since they essentially describe an infinite sequence. It's the type (and thus the POLY_INT_CST in the type) that says how long the sequence should be.
