On Tue, Dec 23, 2014 at 2:24 PM, John David Anglin <dave.ang...@bell.net> wrote:
> On 2014-12-23 12:32 PM, H.J. Lu wrote:
>>
>> On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin <dave.ang...@bell.net>
>> wrote:
>>>
>>> On 8-Dec-14, at 5:36 PM, Jeff Law wrote:
>>>
>>>> On 12/08/14 15:15, John David Anglin wrote:
>>>>>
>>>>> On 12/8/2014 3:01 PM, Jeff Law wrote:
>>>>>>>
>>>>>>> The above is wrong for sibcalls. Sibcall arguments are relative
>>>>>>> to the incoming argument pointer. Is this always the frame
>>>>>>> pointer?
>>>>>>
>>>>>> I don't think it's always the frame pointer. Don't we use an
>>>>>> argument pointer for the PA64 runtime? If I recall, it was the
>>>>>> only port that had a non-eliminable argument pointer at the time.
>>>>>
>>>>> I don't think PA64 is an argument against this as sibcalls don't work
>>>>> in the PA64 runtime (they are disabled in pa.c) because the argument
>>>>> pointer isn't a fixed register. I guess in theory it could be fixed
>>>>> if it was saved and restored across calls.
>>>>
>>>> But there's nothing that says another port in the future won't have
>>>> similar characteristics as the PA, so while the PA isn't particularly
>>>> important, it shows there's cases where arguments won't be accessed by
>>>> the
>>>> FP.
>>>>
>>>>
>>>>> DSE as it stands doesn't look at argument pointer based stores and I
>>>>> suspect they would be deleted with current code.
>>>>
>>>> Agreed.
>>>
>>>
>>>
>>> I believe that this version addresses the above issues. While there may
>>> be
>>> some opportunity to
>>> optimize the handling of sibling call arguments, I think it is more
>>> important to get the overall logic
>>> correct. Also, it's obviously a rare situation for the arguments to be
>>> pushed to the stack.
>>>
>>> Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.
>>>
>> This caused:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388
>>
> I tend to think the dse behavior expected by the testcase is wrong and this
> only worked
> before because the arguments for the call to bar are passed in registers.
>
>
The testcase has
/* { dg-do compile { target { { { { { { { { i?86-*-* x86_64-*-* } && x32 } || lp
64 } && { ! s390*-*-* } } && { ! hppa*64*-*-* } } && { ! alpha*-*-* } } && { { !
powerpc*-*-linux* } || powerpc_elfv2 } && { ! nvptx-*-* } } } } } */
In this case, arguments are passed in registers. Isn't the optimization
disabled for ia32, which passes arguments on stack, even before your
change?
--
H.J.
