On Thu, Jun 23, 2011 at 11:47 PM, Easwaran Raman wrote:
> On Thu, Jun 23, 2011 at 12:16 PM, Jakub Jelinek wrote:
>> On Thu, Jun 23, 2011 at 12:02:35PM -0700, Easwaran Raman wrote:
>>> + if (y_expr)
>>> + mark_addressable (y_expr);
>>
>> Please watch formatting, a tab should be used in
On Thu, Jun 23, 2011 at 12:16 PM, Jakub Jelinek wrote:
> On Thu, Jun 23, 2011 at 12:02:35PM -0700, Easwaran Raman wrote:
>> + if (y_expr)
>> + mark_addressable (y_expr);
>
> Please watch formatting, a tab should be used instead of 8 spaces.
>
>> + if (x_expr)
>> + mark_addr
On Thu, Jun 23, 2011 at 12:02:35PM -0700, Easwaran Raman wrote:
> + if (y_expr)
> +mark_addressable (y_expr);
Please watch formatting, a tab should be used instead of 8 spaces.
> + if (x_expr)
> +mark_addressable (x_expr);
Ditto.
> @@ -1084,6 +1084,8 @@ initialize_argu
On Thu, Jun 23, 2011 at 3:22 AM, Eric Botcazou wrote:
>> So, what's the patch(es) that need approval now?
>
> Original expr.c patch for PR rtl-optimization/49429 + adjusted and augmented
> calls.c patch for PR target/49454. Everything is in this thread.
>
> Easwaran, would you mind posting a cons
> So, what's the patch(es) that need approval now?
Original expr.c patch for PR rtl-optimization/49429 + adjusted and augmented
calls.c patch for PR target/49454. Everything is in this thread.
Easwaran, would you mind posting a consolidated patch?
--
Eric Botcazou
On Thu, Jun 23, 2011 at 10:00 AM, Eric Botcazou wrote:
>> Is the following patch a reasonable fix for this case?
>
> The lines should be moved to within the first branch of the subsequent "if".
> They aren't needed if the second branch is taken because, in this case, we're
> back to the usual call
> Is the following patch a reasonable fix for this case?
The lines should be moved to within the first branch of the subsequent "if".
They aren't needed if the second branch is taken because, in this case, we're
back to the usual caller-copied scheme where we pass the address of the copy.
> I a
On Wed, Jun 22, 2011 at 7:13 AM, Eric Botcazou wrote:
>> I fear this isn't enough considering pass-by-value aggregates that
>> are callee copied.
>
> It's indeed not sufficient for arguments passed by reference but
> callee-copied.
>
> This is PR target/49454. For gcc.c-torture/execute/2717-
> I fear this isn't enough considering pass-by-value aggregates that
> are callee copied.
It's indeed not sufficient for arguments passed by reference but callee-copied.
This is PR target/49454. For gcc.c-torture/execute/2717-1.c:
typedef struct trio { int a, b, c; } trio;
int
foo (trio t,
On Wed, Jun 22, 2011 at 3:14 PM, Jakub Jelinek wrote:
> On Wed, Jun 22, 2011 at 03:08:21PM +0200, Eric Botcazou wrote:
>> > I fear this isn't enough considering pass-by-value aggregates that
>> > are callee copied. And I guess there are other cases. Eric, what
>> > do you suggest here?
>>
>> I a
On Wed, Jun 22, 2011 at 03:08:21PM +0200, Eric Botcazou wrote:
> > I fear this isn't enough considering pass-by-value aggregates that
> > are callee copied. And I guess there are other cases. Eric, what
> > do you suggest here?
>
> I agree that there are probably other cases, but this seems to b
> I fear this isn't enough considering pass-by-value aggregates that
> are callee copied. And I guess there are other cases. Eric, what
> do you suggest here?
I agree that there are probably other cases, but this seems to be the best way
out for now. There is still similar code in the expander
On Tue, Jun 21, 2011 at 3:38 AM, Easwaran Raman wrote:
> This fixes bugs introduced by r175063. OK for trunk if there are no
> test regressions?
I fear this isn't enough considering pass-by-value aggregates that
are callee copied. And I guess there are other cases. Eric, what
do you suggest her
This fixes bugs introduced by r175063. OK for trunk if there are no
test regressions?
-Easwaran
2011-06-20 Easwaran Raman
PR rtl-optimization/49429
* expr.c (emit_block_move_hints): Mark MEM_EXPR(x) and
MEM_EXPR(y) addressable if emit_block_move_via_libcall is
14 matches
Mail list logo
