"Jayant R. Sonar" <Jayant.Sonar@xxxxxxxxxxxxxxx> writes:
> I am working on CR16 port.
>
> Found an improper code is being generated for following part of the test
> code:
> ============================================================================
> IeData = (void *) RAlloc(DataLen);
> LAHType* p = (LAHType*)IeData;
>
> ReadFH (DpEntry, &FeData, &p->Table, &p->Masked, &p->NumAH, &p->Len, TData);
> ============================================================================
>
> Arguments are pushed on to the stack from right to left direction.
> Possible working assembly that could be generated for this code:
> Case 1:
> ================================================================
> bal (ra), _RAlloc@c
> stord (r1,r0), 32(sp)
> addd $-2, (sp)
> .LCFI547:
> movd $18, (r7,r6)
> addd (sp), (r7,r6)
> push $2,r6
> .LCFI548:
> addd $3, (r1,r0)
> push $2,r0
>
> OR lesser optimized code could be:
> Case 2:
> ============================================================
> bal (ra), _RAlloc@c
> stord (r1,r0), 32(sp)
> addd $-2, (sp)
> .LCFI547:
> movd $18, (r7,r6)
> addd (sp), (r7,r6)
> push $2,r6
> .LCFI548:
> loadd 32(sp), (r1,r0)
> addd $3, (r1,r0)
> push $2,r0
>
> However, I am getting following code:
> ============================================================
> bal (ra), _RAlloc@c
> stord (r1,r0), 20(sp)
> addd $-2, (sp)
> .LCFI547:
> movd $18, (r2,r1)
> addd (sp), (r2,r1)
> push $2,r1
> .LCFI548:
> addd $3, (r1,r0) <<============== PROBLEM
> push $2,r0
>
> 'R1' being the part of first push already has some value in it. So before
> next push, either (r1,r0) should be loaded with new address value as shown
> in Case 2. Otherwise, as in Case 1, different register pairs should be used
> for these two push operations.
>
> CR16 port did not have REG_ALLOC_ORDER defined.
> I am trying to control register allocation order using this. However, it
> looks like this sequence has to be decided very carefully as slightest of
> the alternation in sequence are causing some or other application failures.
>
> Is there any other way, I could address this problem?
I don't know this syntax. Are you saying that the instruction
push $2,r1
modifies r1? Or are you saying that that the instruction
addd $3, (r1,r0)
may modify r1, and therefore must be executed before the push
instruction?
Either way, REG_ALLOC_ORDER is not an issue here. You need to look at
the RTL dumps. See whether the original call sequence in the first RTL
dump is valid, using pseudo-registers. Then find out where it becomes
invalid.
One thing to consider is whether the push instruction is particularly
efficient on your processor. If it is not--if it is comparable to a mov
instruction to an offset from sp--then consider defining
ACCUMULATE_OUTGOING_ARGS rather than PUSH_ARGS. Most processors get
more efficient code from ACCUMULATE_OUTGOING_ARGS.
Ian
