another difference in gcc (2v) ?
paubert at iram.es
Thu Apr 12 01:22:22 EST 2001
On Wed, 11 Apr 2001, Kevin B. Hendricks wrote:
> Lost in the huge diff was one other change, this time in the actual code
> Can anyone tell me if this code resequence is legal? The diff (-) lines
> show the nonworking disassembled code (generated by -O2) while the
> diff's (+) lines show the working code (generated by -O2
> -fno-schedule-insns -fno-schedule-insns2.
> Notice that when correct, the "cmpwi r3,0" code comes right before the
> branch ("beq") while in the non-working code it has been resequenced to
> come before lots of other instructions that may be setting a condition
> register value (subf and srawi).
> Is this a correct resequence? I seem to remember something about a "."
> being added to some assmebler instructions to indicate that it impacts a
> condition register yet I see no indication of it in this sequence.
The reordering looks perfectly valid. You are right, the only instructions
that affect condition codes and do not end in a dot are the compare
For most other arithmetic/logic instructions you have the choice of
updating cr0 or not. For a very small subset of instructions, cr0 is
always updated (andi., andis., and stwcx./stdcx.), note that all these
mnemonics end in a dot, and they have no dotless form.
Unless you've found a processor bug, I doubt this is the problem.
> - 1c4: 80 61 00 38 lwz r3,56(r1)
> - 1c8: 80 01 00 44 lwz r0,68(r1)
> - 1cc: 2c 03 00 00 cmpwi r3,0
> - 1d0: 7c 03 00 50 subf r0,r3,r0
> - 1d4: 7c 00 16 70 srawi r0,r0,2
> + 1c4: 80 01 00 44 lwz r0,68(r1)
> + 1c8: 80 61 00 38 lwz r3,56(r1)
> + 1cc: 7c 03 00 50 subf r0,r3,r0
> + 1d0: 7c 00 16 70 srawi r0,r0,2
> + 1d4: 2c 03 00 00 cmpwi r3,0
> 1d8: 41 82 00 14 beq 1ec
> rchicalName(configmgr::configapi::NodeAccess &)+0x1e8>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev