https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
--- Comment #2 from andi at firstfloor dot org --- On Wed, May 15, 2024 at 06:23:27AM +0000, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 > > --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- > maybe represent this in a more formal way: Makes sense. > > node = __builtin_speculate (node + 1, node->next); > > and in GIMPLE: > > _1 = node + 1; > _2 = node->next; > node = .SPECULATE (_1, _2); > > and during RTL expansion leave the desired representation to the targets > which could use an UNSPEC to avoid optimizing it away. There might be speculation constructs that don't use equal in more complex scenarios. For example you could speculate on a binary search. Perhaps could extend it to more conditions? > Formally we'd say __builtin_speculate "uses" the first argument if its > value is equal to the second argument value. > > That said, I heard CPUs have prefetchers that recognize this kind of list > walking. I wonder why they wouldn't then also be able to speculate the > load value like you say. These are on the L2 or L3 level, not L1. This is about hiding L1 latencies, which normally doesn't have a prefetcher. > Oh, and doesn't this explicit speculation of using node++ open up spectre > style attacks? It's not different than any other condition in this regard.
