On 02 August 2007 15:00, Ian Lance Taylor wrote:
> "Pranav Bhandarkar" <[EMAIL PROTECTED]> writes:
>
>>> How can we have a PLUS on a CONST_DOUBLE and a CONST_INT? That does
>>> not make sense, as there is no MODE argument that could make this work
>>> correctly. From your description, MODE must be some integer mode, in
>>> which case it is wrong to be using a CONST_DOUBLE in SFmode.
>>>
>>> (I don't know where the bug is; I'm just trying to help pin it down.)
>> Here it is!!
>> The problem is that for the following insn(insn 20 19 21 2 (set (reg:SI
>> 141) (xor:SI (subreg:SI (reg:SF 139) 0)
>> (reg:SI 140))) 65 {xorsi3} (expr_list:REG_EQUAL
>> (const_double:SF 0 [0x0] -0.0 [-0x0.0p+0])
>> (nil)))
>>
>> reg:SI 140 is known to have the constant value
>> (const_int -2147483648 [0x80000000]))
>> and (subreg:SI (reg:SF 139) 0) is known to have the value
>> (const_double:SF 0 [0x0] 0.0 [0x0.0p+0]) [ as described by my
>> previous post in the same thread ]
>
> (reg:SF 139) can hold the value (const_double:SF 0) but (subreg:SI
> (reg:SF 139)) should be the value (const_int 0). Perhaps the problem
> is how we handle a REG_EQUAL note when the destination of the set is a
> SUBREG.
>
> Ian
Yes, absolutely so, we already know that there are problems there. For
references, see the threads "Deep CSE bug!"[*] and "Bogus REG_EQUIV note
generation"[**] (subject line was wrong, should have been REG_EQUAL all along)
from June last year, where we got some way into analysing the problem. I
/think/ that the presence of REG_RETVAL in this particular case is only
tangential to the problem; from what I remember of the discussion, this is
just about Gcc incorrectly handling reg notes when it decomposes
multi-word-size-mode moves into individual word-sized moves.
Pranav, although there is indeed a bug in the mid-end here, from your point
of view the simple and effective workaround should be to implement a movdi
pattern (and movsf and movdf if you don't have them yet: it's an absolute
requirement to implement movMM for any modes you expect your machine to
handle) in the backend. This won't fix the underlying bug, but it'll stop it
from affecting you, and you'll get better codegen all round into the bargain
if you expand movdi early.
cheers,
DaveK
[*] - http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html
[**] - http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html
--
Can't think of a witty .sigline today....
