On Wed, 6 Jan 2021, Richard Sandiford wrote: > VOIDmode const_doubles should only be used for integers that cannot > be expressed as a sign-extended HOST_WIDE_INT. So (const_double 0 0) > is an invalid rtx in both integer and FP contexts.
The updated change makes the VAX and PDP-11 backends stop producing those, but as I noted this is IMHO tangential to the choice between CONST0_RTX and CONST_DOUBLE_ATOF for code generators produced from named insns. And the latter does not interpret the mode, i.e. does not enforce the policy (which itself I don't argue against), leaving it up to people writing machine descriptions to get it right, which I think is the right place. > (FTR, the constant should also be the second operand to the plus, > but that's obviously tangential.) Also FTR, I made it the first one deliberately, as I made my experimental change across all the four basic arithmetic operations, so for obvious reasons I wanted to prevent a divisor from being 0 lest the middle end get anxious about it. Also contrary to documentation the middle end does present constants as the first operand in some cases where it is not supposed to (and does insist on doing so even if the backend says it's more expensive), as it was previously discussed in the context of COMPARE. Actually the VAX machine operand syntax is generic enough you can have an immediate as any operand, and in particular the first input to binary operations -- e.g. the minuend, and obviously also the first addend -- in their three-operand encodings; all the four basic arithmetic operations have them. I have posted the updated change as a patch series now, including you in the list of the recipients in case you wanted to chime in. I appreciate your feedback and experience in this area, thank you! Maciej
