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?
