Currently, we
- match LHS matcher to the first operand of binary operator,
- and then match RHS matcher to the second operand of binary operator.
If that does not match, we swap the LHS and RHS matchers:
- match RHS matcher to the first operand of binary operator,
- and then match LHS matcher to the second operand of binary operator.
This works ok.
But it complicates writing of commutative matchers, where one would like to match
(m_Value()) the value on one side, and use (m_Specific()) it on the other side.
This is additionally complicated by the fact that m_Specific() stores the Value *,
not Value **, so it won't work at all out of the box.
The last problem is trivially solved by adding a new m_c_Specific() that stores the
Value **, not Value *. I'm choosing to add a new matcher, not change the existing
one because i guess all the current users are ok with existing behavior,
and this additional pointer indirection may have performance drawbacks.
Also, i'm storing pointer, not reference, because for some mysterious-to-me reason
it did not work with the reference.
The first one appears trivial, too.
Currently, we
- match LHS matcher to the first operand of binary operator,
- and then match RHS matcher to the second operand of binary operator.
If that does not match, we swap the LHS and RHS matchers operands:
- match
RHSLHS matcher to thefirstsecond operand of binary operator, - and then match
LHSRHS matcher to the ~~second~ first operand of binary operator.
Surprisingly, $ ninja check-llvm still passes with this.
But i expect the bots will disagree..
The motivational unittest is included.
I'd like to use this in D45664.