Re: Code emitted was bloated with no optimisation.
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. add WA, IX ... ld HL, 1 ld (SP+2), HL cmp WA,IX j lt,_.L2 ld DE, 0 ld (SP+2), DE .L2: I'm not sure why such an addition would be necessary, but in any case the port is probably lacking a cstoresi4 pattern (you can use a predicate for operand 2 that only matches LTU). Paolo
Re: Code emitted was bloated with no optimisation.
Andrew Haley a...@redhat.com 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-hand how a[i] would generate a branch, for starters. But it's very hard to answer this kind of question for a private port. How is Pmode defined? If it's a partial integer mode like PSImode, is the problem that the arithmetic is being done in SImode? Thanks, Richard
Re: Code emitted was bloated with no optimisation.
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 IX, WA ld BC, 15 cal _C87C_shris ld IY, WA ld DE, WA ld HL, BC ld WA, IX add WA, IX ld DE, WA ld WA, DE ld BC, HL ld HL, 1 ld (SP+2), HL cmp WA,IX j lt,_.L2 ld DE, 0 ld (SP+2), DE .L2: ld DE, WA ld HL, BC ld BC, IY add BC, IY ld HL, BC ld WA, DE ld BC, HL ld DE, (SP+2) add DE, BC ld BC, DE ld HL, WA ld (SP+0), HL ld WA, 20 ld HL, (SP+0) ld (a+i), WA Anyidea why it so ?? Thank you in advance ~Umesh On Thu, Apr 10, 2014 at 8:54 PM, Andrew Haley a...@redhat.com wrote: 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.
Re: Code emitted was bloated with no optimisation.
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 rsand...@linux.vnet.ibm.com wrote: Andrew Haley a...@redhat.com 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-hand how a[i] would generate a branch, for starters. But it's very hard to answer this kind of question for a private port. How is Pmode defined? If it's a partial integer mode like PSImode, is the problem that the arithmetic is being done in SImode? Thanks, Richard
Re: Code emitted was bloated with no optimisation.
Umesh Kalappa umesh.kalap...@gmail.com 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 .expand dumps for the optimised and unoptimised code. If they both use the same bad sequence, see (a) which pass manages to optimise it and (b) figure out why the expand-time code is so bad. If the difference is already present at expand time then presumably something is going wrong earlier. Thanks, Richard
Re: Code emitted was bloated with no optimisation.
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.
