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
