On 27 July 2007 18:24, Ian Lance Taylor wrote:
> "Pranav Bhandarkar" writes:
>
>> I am working on a private port and am seeing the following problem.
>> For a function returning a double the value is stored by the function
>> in memory. cse removes one of the two loads (to retrieve this returned
>> value) after the function is called.
>>
>> cse modifies insn 48 as
>>
>> (insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
>> (reg:SI 178 [+4 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
>> (const_int 2 [0x2]) (expr_list:REG_EQUAL (float:DF (reg:SI 136 [
>> D.1517 ])) (nil)))) (nil))))
>>
>> and also replaces every subsequent use of (reg:SI 180 [+4 ]) with
>> (reg:SI 178 [+4 ]) thus making the above load dead, which gets
>> subsequently removed. This way the result of the function call is
>> lost.
>> My take is that insn 48 should have a REG_RETVAL note ( Infact it
>> does have this but the note is removed by lower_subreg) and cse should
>> be careful when REG_RETVAL and REG_EQUAL appear in the same insn. Is
>> this the right way of going about it ?
>
> Am I reading your code correctly when it appears that the
> __floatunsidf function returns a value in memory rather than via a
> register?
>
> If lower-subreg split up the load from memory, then it was correct to
> remove the REG_RETVAL note. There may be a bug here in that it should
> also remove the REG_EQUAL note in that case. It may be that
> remove_retval_note needs to look for and remove a REG_EQUAL note.
Or perhaps this could be another manifestation of the "cse gets confused by
reg_equal notes on subparts of dimode pseudos if no movdi pattern is defined
in the backend" bug[*]? Pranav, is there a movdi pattern in your backend?
There needs to be one, gcc does get it wrong if you rely on it to break
everything down to si-sized movs.
cheers,
DaveK
--
Can't think of a witty .sigline today....
