https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 8 Jul 2025, kristerw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980 > > --- Comment #8 from Krister Walfridsson <kristerw at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #7) > > Hmm, I don't quite follow the difference between GIMPLE and C here. > > For both to get from one to another object you have to go via > > integer arithmetic, not pointer arithmetic. > > [...] > > The point I was trying to make is that the semantic impact of provenance is > different in C and GIMPLE, and the intuition from C doesn't completely carry > over to GIMPLE. > > In C, essentially everything that is UB due to provenance is already UB due to > a pointer pointing outside of an object. So we can tweak how we use provenance > without causing major issues. > > But we have to be much more careful in GIMPLE, because its pointer rules are > more permissive, so provenance has a much bigger impact. > > That said, my example was bad -- it has the same issue for both C and > GIMPLE... > :( > > But I still think the example illustrates why I don't think we can make a > workable semantic for handling out-of-bounds loads. > > > > That of course makes the vectorizer behavior bad again if the > > pointer now hits an unrelated object (but with your verifier, how > > do you "place" objects so that you ever possibly reach one from > > another?) > > The current version of the tool places objects far from each other, but I plan > to change the layout to be more realistic, and to better support things like > section anchors. > > For now, I think a workable solution is to set a limit on how far > out-of-bounds > an access may be, and to allow fully out-of-bounds loads within that range (as > long as they are on the same page as the last byte of the object). And maybe > only when loading using a vector type? What is the maximum out-of-bounds > distance we need to handle? I fear it would be page_size - 1 given we already have to watch out for this in the vectorizer itself. Consider AVX512 vectors when you have both 'char' and 'double' data, you get a VF of 64 and 8 times V8DF data accesses from that, so a single vector iteration accesses at least 512 bytes worth of 'double' data. Now combine that badly with SLP opportunities (only 8 manual unroll iterations for one of the data) and you get to 4096 bytes. Not unrealistic. You'd then have in the extreme 64 bytes in-bound (from the manual unroll) and 4032 bytes out-of-bound.
