<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><small>On 08/13/2015 01:43 PM, James
Molloy wrote:<br>
</small></div>
<blockquote
cite="mid:CALCTSA1x+jH1xeL1J5gQvmEf0PU_Xd_g7oHFdkvHRV8onAFqcQ@mail.gmail.com"
type="cite"><small>Hi Matt,</small>
<div><small><br>
</small></div>
<div><small>Yes; min/max is now matched at the IR level. I know
there is the possibility of this approach missing some
min/max's exposed at the DAGCombine level, but that could be
fixed with point fixes if a common pattern emerges.</small></div>
<div><small><br>
</small></div>
<div><small>The advantage of matching at the SDAGBuilder stage is
that all the (fairly complex) logic gets kept in one place.
We've now (or will have by the end of the week) removed 4
separate implementations of matching mins/maxs, all dealing
with the subtleties of
orderedness/unorderedness/signed-zeroes/NaNs. I hope that in
the long run this new approach will be more maintainable, and
I'm sure we can patch up any regressions in DAGCombine.</small></div>
<div><small><br>
</small></div>
<div><small>James</small></div>
</blockquote>
<small><br>
I've found a problem with this approach. On AMDGPU we don't have
any vector operations, but legal vector types. We only really care
about legality of the scalar operations, but because we have the
min/max nodes set to expand on vectors, the IR pattern matching
doesn't trigger. I think we should bring back a DAG pattern match
for this to catch these cases<br>
<br>
-Matt<br>
<small></small></small>
</body>
</html>