On Tue, Dec 23, 2014 at 6:59 PM, Jeff Law wrote:
> On 12/23/14 19:47, H.J. Lu wrote:
>>
>> On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin
>> wrote:
>>>
>>> On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
>>>
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
wrote:
>
>
>
On 12/23/14 19:47, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin wrote:
On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
wrote:
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't
On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin wrote:
> On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
>
>> On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
>> wrote:
>>>
>>> On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
>>>
In this case, arguments are passed in registers. Isn't the
optimi
On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin > wrote:
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't the
optimization
disabled for ia32, which passes arguments on stack, even before your
change?
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin wrote:
> On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
>
>> In this case, arguments are passed in registers. Isn't the optimization
>> disabled for ia32, which passes arguments on stack, even before your
>> change?
>
>
> It's not disabled in dse.c.
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't the
optimization
disabled for ia32, which passes arguments on stack, even before your
change?
It's not disabled in dse.c. Possibly, this occurs for some cases for
ia32 in ix86_function_ok_for
On Tue, Dec 23, 2014 at 2:24 PM, John David Anglin wrote:
> On 2014-12-23 12:32 PM, H.J. Lu wrote:
>>
>> On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin
>> 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
On 2014-12-23 12:32 PM, H.J. Lu wrote:
On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin 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
On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin 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 arg
On 12/19/14 16:45, John David Anglin wrote:
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 th
On 16-Dec-14, at 8:17 PM, John David Anglin 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
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
12 matches
Mail list logo
