Andy, et al.,
I'm experimenting with better condition-register-bit tracking in the PowerPC
backend, and I've run across a problem: the scheduling seems to be
scheduling glued nodes out of order:
Starting with this:
0x10015677970: i32 = Register %CR0
0x10015679080: i32 = TargetConstant<3>
...
0x10015671b80: i32 = TargetConstant<1>
0x10015678d80: i32,glue = ANDIo 0x100156746c0, 0x10015671b80 [ORD=49]
0x100156749c0: i1 = EXTRACT_SUBREG 0x10015677970, 0x10015679080,
0x10015678d80:1 [ORD=49]
0x10015671d80: ch = CopyToReg 0x100156463c8, 0x10015677c70, 0x100156749c0
[ORD=49]
...
the two glued nodes are put together in the same SU:
SU(2): 0x100156749c0: i1 = EXTRACT_SUBREG 0x10015677970, 0x10015679080,
0x10015678d80:1 [ORD=49] [ID=2]
0x10015678d80: i32,glue = ANDIo 0x100156746c0, 0x10015671b80 [ORD=49] [ID=2]
and scheduled together, yielding this schedule:
SU(3): 0x100156746c0: i32,ch = LWZ 0x10015674fc0, 0x10015678b80,
0x10015672280<Mem:LD4[FixedStack1+8](align=8)> [ORD=49] [ID=3]
SU(2): 0x100156749c0: i1 = EXTRACT_SUBREG 0x10015677970, 0x10015679080,
0x10015678d80:1 [ORD=49] [ID=2]
0x10015678d80: i32,glue = ANDIo 0x100156746c0, 0x10015671b80 [ORD=49] [ID=2]
SU(1): 0x10015671d80: ch = CopyToReg 0x100156463c8, 0x10015677c70, 0x100156749c0
[ORD=49] [ID=1]
SU(0): 0x100156762d0: ch = TokenFactor 0x10015678c80, 0x10015679180,
0x10015671d80 [ORD=50] [ID=0]
which then asserts:
llvm-trunk/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:292: unsigned int
llvm::InstrEmitter::getVR(llvm::SDValue, llvm::DenseMap<llvm::SDValue,
unsigned int, llvm::DenseMapInfo<llvm::SDValue> >&): Assertion `I
!= VRBaseMap.end() && "Node emitted out of order - late"'
failed.
What's gone wrong here? Is the order in the SU wrong, or should the
scheduler invert the order for scheduling, or something else?
Thanks again,
Hal
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
