Hi Jeff,
Yes I will create a test case. I'm not quite sure what to check for even
in the machine dependent test case. It's quite possible for the
instructions that are generated to change over time.
On 7/31/2015 9:20 AM, Jeff Law wrote:
On 07/28/2015 01:41 AM, Richard Biener wrote:
The above case is a corner case I think - the number of && you can
change
into (multiple) MIN/MAX is unbound but we might only care about the case
where there will be one MIN/MAX operation.
I suspect that's going to be the most important/common case.
Generally phiopt and other patterns that match the CFG are not yet well
supported by match.pd (though I outlined how matching PHI nodes when
facing (simplify (cond ...) ...) would be possible).
Right. Though I thought the conclusion after outlining we determined
it wasn't really feasible, yet.
So while putting something into match.pd is easy I'd like people to
think if doing the same thing elsewhere is better - that is, if this
is really
a pattern transform operation or if you are just implementing a
special-case
of a general transform as a pattern.
So in this case we're taking something like:
_6 = i_1 < m_4(D);
_7 = i_1 < n_3(D);
_8 = _6 & _7;
if (_8 != 0)
And turning it into
_X = MIN (m_4, n_3)
if (i_1 < _X)
That seems to me like a good match for match.pd given its generality
and the need to walk up the use-def chain. It's certainly not a good
fit for phi-opt since we're not looking at PHIs :-)
Michael -- can you take your sample code and turn it into a test for
the testsuite. I'd hazard a guess it'll need to be target specific
because of its interactions with branch-costing. Might as well make 4
variants (lt -> MIN, le -> MIN, ge->MAX, gt->MAX).
We're going to want that regardless of whether tackling this issue in
match.pd (my current preference) or elsewhere.
jeff
