https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #20 from kugan at gcc dot gnu.org --- (In reply to Richard Sandiford from comment #19) > (In reply to Richard Biener from comment #14) > > Usually targets do have a limit on the actual length but I see > > constant_upper_bound_with_limit doesn't query such. But it would > > be a more appropriate way to say there might be an actual target limit here? > The discussion has moved on, but FWIW: this was a deliberate choice. > The thinking at the time was that VLA code should be truly “agnostic” > and not hard-code an upper limit. Hard-coding a limit would be hard-coding > an assumption that the architectural maximum would never increase in future. > > (The main counterargument was that any uses of the .B form of TBL would > break down for >256-byte vectors. We hardly use such TBLs for autovec > though, and could easily choose not to use them at all.) > > That decision is 8 or 9 years old at this point, so it might seem overly > dogmatic now. Even so, I think we should have a strong reason to change > tack. > It shouldn't just be about trying to avoid poly_ints :) Thanks. I have posted an RFC at https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659373.html In addition to making loop->safelen POLY_INT, I also change the apply_safelen with: + unsigned int safelen; + if (loop->safelen.is_constant ()) + safelen = loop->safelen.coeffs[0]; + else + safelen = INT_MAX; That is. in essence this would be an INT_MAX in these cases.
