On Tue, Oct 13, 2026 at 11:37 AM Uros Bizjak <[email protected]> wrote: > > On Tue, Oct 13, 2026 at 11:06 AM Richard Biener > <[email protected]> wrote: > > > > On Tue, Oct 13, 2026 at 10:45 AM Vineet Gupta <[email protected]> > > wrote: > > > > > > With -ffuse-ops-with-volatile-access general_operand accepts volatile > > > MEMs during combine. For "int a = x; int b = y; return a < b;" with > > > volatile x and y, combine first merges the load of y into the compare > > > and then the load of x, giving (compare (mem/v x) (mem/v y)). The > > > > Why does this pass recog when it later needs reloading? > > For some unknown (historical ?) reasons, compare with two memory > operands, is allowed in i386.md. The compiler should not create > invalid instructions that burden LRA unnecessarily, so I'm testing a > patch that simply rejects them. This is a simple defensive target > patch, but it will paper over real problems, addressed in Vineet's > patch.
The idea was probably that LRA would reload the "better" memory operand. The problem is of course that we tend to "un-CSE" loads when they are valid as memory operands, even in multiple uses (and postreload CSE is weak) Richard. > > Uros.
