Il 11/04/2014 07:05, Richard Sandiford ha scritto:
Sure, but this is a bit extreme. I don't see off-hand how a[i]
would generate a branch, for starters.
That's an HI+HI->SI addition, with the higher half stored in (SP+2).
The jump is emitted by cstore in order to compute the carry.
Umesh Kalappa writes:
> Richard ,
> Pmode is defined HImode and private target is 16 bit where int ,short
> and Pmode is defined HImode and long as SImode.
>
> Please do let me know if it requires more information on the target.
In that case I suggest you compile with -da and compare the .expa
Richard ,
Pmode is defined HImode and private target is 16 bit where int ,short
and Pmode is defined HImode and long as SImode.
Please do let me know if it requires more information on the target.
Thank you
~Umesh
On Fri, Apr 11, 2014 at 4:35 PM, Richard Sandiford
wrote:
> Andrew Haley writ
Hi Andrew,
Appreciate your reply here and yes unoptimized code is expected to be
large ,but for the construct like a[i] the below generated code looks
crazy to me .
ld WA, 10
ld (_a+18), WA ; a[9] = 10;
ld WA, (_i) ;code bloated here for a[i]
ld
Andrew Haley writes:
> On 04/10/2014 04:12 PM, Umesh Kalappa wrote:
>
>> Please somebody from the group can share their thoughts and will be
>> appricate the same.
>
> But unoptimized code is expected to be large. Why do you expect
> otherwise?
Sure, but this is a bit extreme. I don't see off-h
On 04/10/2014 04:12 PM, Umesh Kalappa wrote:
> Please somebody from the group can share their thoughts and will be
> appricate the same.
But unoptimized code is expected to be large. Why do you expect
otherwise?
Andrew.
Hi there,
we ported gcc 4.8.1 to our ptivate target and the code is bloated for
the array access as shown below
C file :
int a[10];
int i;
test()
{
a[9] = 10;
a[i] = 20;
}
xgcc -O2 -S test.c
_test:
ld (_a+18), 10 ;a[9] = 10;
ld WA, (_i) ; a[i] = 20;
add WA
