On 11/1/26 8:31 PM, Jeff Law wrote:
FYI, the i386.md fix was specific to compare patterns, and as Jeff
pointed out, that approach results in a maintenance hell, as it
requires manually changing all RTX patterns that accept two or more
memory operands with the insn check that allows at most one volatile
operand. AFAICS, the same effect can be achieved in recog_for_combine
with some RTX walker that rejects invalid RTXes at the point of
recognition. I don't know if this is the most optimal solution, but as
shown with my i386.md experiment, it works.
Eh, no. Combine can split insns internally, and we have to reject
combined insns with multiple volatile ops before they get split.
Feels like we need to catch this class of problems when we have the
unaltered i0..i3. There's a ton of code to reject classes of
combinations that aren't going to work for some reason or another, this
feels like just another set of constraints to encode there. Of course,
I'm not inside the code, so I may be drastically oversimplifying.
For v5 which I have currently tested (and bootstrapped on x86 and
arm64) this is done post split and it allows the split results only if
the orig order is maintained for which it needs to snapshot the order
before.
What Uros and you are suggesting here is to check pre-split and if I
understand correctly reject whenever the combine pattern has volatile
reads from two different insns, w/o worrying about the ordering at all
? This might actually be simpler, as it avoids the snapshoting. Let me
give this a try.
But in the mean time I can send out v5 as it now.
I was coming at it from the angle of you can't know order once you start
those SUBST calls. So ISTM that you want to check fairly early.
The v5 posted at [1] does it super early.
Thx,
-Vineet
[1]
https://inbox.sourceware.org/gcc-patches/[email protected]/
