On Wed, Jan 4, 2012 at 5:24 PM, Eric Botcazou wrote:
>> OK. But passing small structures by value doesn't seem that rare --
>> especially in C++ -- and it doesn't feel right to disable SRA just because
>> the backend likes to increase the alignment of stack vars.
>
> Agreed.
>
>> ...something lik
Eric Botcazou writes:
> Regtested on SPARC/Solaris. Can you confirm that this fixes the
> pessimization in all cases (and run the C testsuite for your favorite
> ABI variant)? TIA.
It does, and there were no regression on a C-only build & test for
mips64-linux-gnu (-mabi=32/-mips16, -mabi=32, -
> OK. But passing small structures by value doesn't seem that rare --
> especially in C++ -- and it doesn't feel right to disable SRA just because
> the backend likes to increase the alignment of stack vars.
Agreed.
> ...something like this sounds good, although you seem less than happy
> with i
On Tue, Jan 3, 2012 at 12:26 PM, Eric Botcazou wrote:
>> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
>> are BLKmode? I suppose they are, in this case. Or should we truncate
>> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
>> than that to avo
Eric Botcazou writes:
>> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
>> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
>> SRA test, but in this case I think it really is showing a genuine problem.
>> We have:
>>
>> struct a {int a,b,c;} a
> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
> are BLKmode? I suppose they are, in this case. Or should we truncate
> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
> than that to avoid this situation?
Sorry, I didn't read your message befor
> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
> SRA test, but in this case I think it really is showing a genuine problem.
> We have:
>
> struct a {int a,b,c;} a;
> int test(struct a a)
On Mon, Jan 2, 2012 at 8:00 PM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> You are basically (but non-optimally) locally re-implementing
>>> what expr.c:get_object_or_type_alignment does, for the
>>> bare MEM_REF case (you don't consider offsets that
>>> do not change the alignment, nor
Eric Botcazou writes:
>> You are basically (but non-optimally) locally re-implementing
>> what expr.c:get_object_or_type_alignment does, for the
>> bare MEM_REF case (you don't consider offsets that
>> do not change the alignment, nor alignment information
>> present on the SSA name).
>
> Adjusted
On Wed, Dec 7, 2011 at 3:32 PM, Eric Botcazou wrote:
>> You are basically (but non-optimally) locally re-implementing
>> what expr.c:get_object_or_type_alignment does, for the
>> bare MEM_REF case (you don't consider offsets that
>> do not change the alignment, nor alignment information
>> present
> You are basically (but non-optimally) locally re-implementing
> what expr.c:get_object_or_type_alignment does, for the
> bare MEM_REF case (you don't consider offsets that
> do not change the alignment, nor alignment information
> present on the SSA name).
Adjusted version attached, regression-t
> You are basically (but non-optimally) locally re-implementing
> what expr.c:get_object_or_type_alignment does, for the
> bare MEM_REF case (you don't consider offsets that
> do not change the alignment, nor alignment information
> present on the SSA name).
Gosh. And now I distinctly remember su
On Tue, Dec 6, 2011 at 11:24 PM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline and 4.6 branch at -O for the SPARC.
> The compiler generates an unaligned access for the memcpy call in:
>
> char *s
>
> union
> {
> int32_t i;
> char a[sizeof (int32_t)];
> }
> v;
>
Hi,
this is a regression present on mainline and 4.6 branch at -O for the SPARC.
The compiler generates an unaligned access for the memcpy call in:
char *s
union
{
int32_t i;
char a[sizeof (int32_t)];
}
v;
memcpy (v.a, s, sizeof (int32_t));
The memcpy call is folded to an
14 matches
Mail list logo
