> > And thus it may be more RTL friendly to represent it this way instead of > > current unspec called UNSPEC_IEEE_MAX... > > There's a patch proposed for that [1], and Jakub has some comments. > > Jakub Jelinek <ja...@redhat.com> 于2024年11月15日周五 16:20写道： > > > > On Fri, Nov 15, 2024 at 04:04:55PM +0800, Hongyu Wang wrote: > > > Following the discussion in pr116738, the insn for UNSPEC_IEEE_MAXMIN > > > actually matches the behavior of if_then_else, so remove the UNSPEC and > > > rewrite related pattern with if_then_else. > > > > I'm not sure if it is necessarily always a win. > > It has an advantage that simplify-rtx can simplify it if the operands are > > constant and better describes what's going on. > > The disadvantage I see is that it has multiple uses of the operands, each > > operand is used twice rather than once in the pattern, which could lead to > > combiner or other optimizations giving up on it. > > > > So, do you see any code generation changes with this patch on something > > larger? > > with Hongyu's replied > --- > I ran spec2017 with O2 config and found some bad changes such as vmaxsd > does not use mem operands. The reload creates extra load for the new pattern. > So maybe we need to preserve current UNSPEC. > ---
Thanks, that is a fair point I did not think of. In a way I wonder if this justifies adding the IEEE and C-style floting point min/max as native RTL codes (to rtl.def). Support for SMIN/SMAX in RTL land seems rather easy. Honza
