Re: rfc: constant pool and floats

[Aldy Hernandez <aldyh at redhat dot com>]

> That's the problem.  Clearly, (reg:SF 120) is not equal to the
> CONST_INT; it's equal to a SFmode CONST_DOUBLE.

I played around kludging the REG_EQUAL to be equal to a CONST_DOUBLE.
That didn't fix the problem because when we fill in the constant pool
(force_const_mem) with the value, we fill it in with a const_int/SFmode
pair, which still causes the abort while dumping the constant pool.

I can see 3 possible solutions:

(a) Change the const_int appropriately when filling in the constant pool
    (in force_const_mem).

(b) Change the const_int in the backend before we call force_const_mem.

(c) Remove the code creating the const_int in the first place, thus
    keeping the const_double as is.  The offending code is:

  /* If VALUE is a floating-point mode, access it as an integer of the
     corresponding size.  This can occur on a machine with 64 bit registers
     that uses SFmode for float.  This can also occur for unaligned float
     structure fields.  */
  if (GET_MODE_CLASS (GET_MODE (value)) != MODE_INT
      && GET_MODE_CLASS (GET_MODE (value)) != MODE_PARTIAL_INT)
    value = gen_lowpart ((GET_MODE (value) == VOIDmode
			  ? word_mode : int_mode_for_mode (GET_MODE (value))),
			 value);

All 3 options fix the regression, and PR1004.

What do you suggest?  I don't understand if the code in question (snippet 
above) is correct or not.

Thanks in advance.
Aldy