Re: [PATCH] genemit: Handle `const_double_zero' rtx

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Wed, 16 Dec 2020, Richard Sandiford wrote:

> >> Presumably you can't use CONST0_RTX (mode) here?  Assuming that's the
> >> case, then this is fine.
> >
> >  Well, `mode' is VOID for simplicity and to match what the middle end 
> > presents as an operand to the COMPARE operation, as also shown with the 
> > diff above, so with CONST0_RTX (mode) we'd be back to what amounts to 
> > `const0_rtx' aka `const_int 0', which is exactly what we want to get away 
> > from.
> >
> >  Alternatively we could possibly give `const_double_zero' a proper FP 
> > mode, but it seems to me like an unnecessary complication, as it would 
> > then have to be individually requested and iterated over all the relevant 
> > modes.
> 
> Generated FP const_double rtxes have to have a proper (non-VOID) mode
> though.  VOIDmode CONST_DOUBLEs are always (legacy) integers instead
> of FP values.
> 
> So yeah, giving const_double_zero a proper mode seems like the way to go.
> It's technically possible to drop it in a pure matching context, but I'm
> not sure how valuable that is in practice, given that other parts of the
> matched pattern would usually need to refer to the same mode anyway.

 Fair enough.  For some reason however VOIDmode CONST_DOUBLEs seem to work 
with the FP operations in the VAX backend for the purpose of post-reload 
comparison elimination while CONST_INTs do not.

> >  Have I missed anything here?
> >
> >  NB the PDP-11 pieces affected here and tripping this assertion are I 
> > believe dead code, as these insns are only ever produced by splitters and 
> > do not appear to be referred by their names.  We need this change however 
> > for completeness so that `const_double_zero' can be used in contexts where 
> > an insn actually will be referred by its name.
> >
> >  However the PDP-11 code being dead makes it a bit more difficult to 
> > examine actual consequences of such a change like I have proposed than it 
> > would otherwise be.  In these circumstances I think my proposal is safe if 
> > a bit overly cautious.
> 
> CONST_DOUBLE_ATOF ("0", VOIDmode) seems malformed though, and I'd expect
> it to assert in REAL_MODE_FORMAT (via the format_helper constructor).
> I'm not sure the patch is strictly safer than the status quo.

 I may have missed that, though I did follow the chain of calls involved 
here to see if there is anything problematic.  As I say I have a limited 
way to verify this in practice as the PDP-11 code involved appears to me 
to be dead, and the situation does not apply to the VAX backend.  Maybe I 
could simulate it somehow artificially to see what happens.

> FWIW, I agree with Jeff that this ought to be CONST0_RTX (mode).

 I'll have to update several places then and push the changes through full 
regression testing, so it'll probably take until the next week.

 Thanks for your input!

  Maciej