Re: [PATCH] Fix PR optimization/11637 (x86)

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> I would suggest that that entire pair of blocks be replaced by
>
>   else if (GET_CODE (x) == CONST_DOUBLE
>            && (GET_MODE (x) == DFmode || GET_MODE (x) == XFmode
>
>                || GET_MODE (x) == TFmode))
>
>     abort ();
>
> as DFmode and wider constants should not ever get here, they are
> always supposed to be spilled to memory.  (x86-64 has a way to load a
> 64-bit immediate but only to integer registers.)

I'll prepare a patch for mainline.

> Well, attaching the REG_EQUAL note to that SET is clearly wrong.  What
> happened to the REG_EQUAL note on the original SFmode SET? That was
> the one that should have been preserved.

Sorry for not being clear enough: the first insn (more precisely its pattern) 
is merged in the second insn (inside the parallel), then replaces the former 
pattern entirely because of the removal of the first set. No REG_EQUAL note 
is touched at all.

> It seems likely to me that this is a simple mistake in the machinery to
> update REG_NOTES etc.

No, the updating machinery basically ignores REQ_EQUAL notes (see 
combine.c:12565).

We could fix it in the present case, by detecting that the first insn has 
totally replaced the second one. And the same problem may happen for 
LOG_LINKS so we should fix this second machinery too.

Or we could simply disable the faulty optimization (see the comment line 
2027).

> If this turns out to be too invasive, your original patch is probably an
> okay band-aid for 3.3; I doubt any program's performance seriously
> relies on being able to load SFmode quantities with immediate move.

I would certainly not commit it myself :-)

-- 
Eric Botcazou