Hello,
I saw a bug in sched1 where it reorders two unspec_volatile
instructions. These instructions do port communications (from the same
port) and doing them in the wrong order is unacceptable. I digged a bit
deeper to see what is happening. Going into sched1, the relevant bit of
basic block is
(debug_insn 184 183 185 12 autogenerated_UlSymbolRateCtrlDummy.c:58
(var_location:SI converter$rawValue (unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) -1 (nil))
(insn 185 184 186 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:58
(set (subreg:SI (reg/v:DI 299 [ trchHeader ])
0)
(unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) 80 {commsGet} (nil))
(note 186 185 188 12 NOTE_INSN_DELETED)
(note 188 186 189 12 NOTE_INSN_DELETED)
(insn 189 188 190 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:58
(set (reg:HI 280 [ trchHeader$D1530$channelCodingEnum ])
(lshiftrt:HI (subreg:HI (reg/v:DI 299 [ trchHeader ]) 0)
(const_int 14 [0xe]))) 64 {lshrhi3} (nil))
(debug_insn 190 189 191 12 (var_location:QI
trchHeader$D1530$channelCodingEnum (subreg:QI (reg:HI 280 [
trchHeader$D1530$channelCodingEnum ]) 0)) -1 (nil))
(debug_insn 191 190 192 12 (var_location:QI
trchHeader$D1530$channelCodingEnum (subreg:QI (reg:HI 280 [
trchHeader$D1530$channelCodingEnum ]) 0)) -1 (nil))
(note 192 191 193 12 NOTE_INSN_DELETED)
(debug_insn 193 192 194 12 autogenerated_UlSymbolRateCtrlDummy.c:58
(var_location:SI converter$rawValue (unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) -1 (nil))
(insn 194 193 195 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:59
(set (subreg:SI (reg/v:DI 299 [ trchHeader ]) 4)
(unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) 80 {commsGet} (nil))
Note that 185 and 194 are the actual port communication instructions
here. If i look at the scheduler forward dependency for this basic block
(at sched1), it looks like this
;; ======================================================
;; -- basic block 12 from 185 to 212 -- before reload
;; ======================================================
;; --------------- forward dependences: ------------
;; --- Region Dependences --- b 12 bb 0
;; insn code bb dep prio cost reservation
;; ---- ---- -- --- ---- ---- -----------
;; 185 80 12 0 2 1 slot1 : 212 193 191
190 189
;; 189 64 12 1 1 1 slot0|slot1 : 212 193 191 190
;; 190 -1 12 2 0 0 nothing : 193 191
;; 191 -1 12 3 0 0 nothing : 193
;; 193 -1 12 4 0 0 nothing : 199 194
;; 194 80 12 0 5 1 slot1 : 212 206 205
204 203 202 201 200 199 198
;; 198 64 12 1 4 1 slot0|slot1 : 212 206 202
200 199
;; 199 -1 12 3 0 0 nothing : 206 200
;; 200 -1 12 3 0 0 nothing : 206 201
;; 201 -1 12 2 0 0 nothing : 206 202
;; 202 -1 12 3 0 0 nothing : 206 203
;; 203 -1 12 2 0 0 nothing : 206 204
;; 204 -1 12 2 0 0 nothing : 206 205
;; 205 -1 12 2 0 0 nothing : 207 206
;; 206 82 12 2 3 1 slot1 : 212 210 209
208 207
;; 207 -1 12 2 0 0 nothing : 210 208
;; 208 -1 12 2 0 0 nothing : 210 209
;; 209 -1 12 2 0 0 nothing : 211 210
;; 210 82 12 1 2 1 slot1 : 212 211
;; 211 -1 12 2 0 0 nothing :
;; 212 7 12 6 1 1 (slot0+slot1+slot2) :
;; dependencies resolved: insn 185
;; tick updated: insn 185 into ready
;; dependencies resolved: insn 194
;; tick updated: insn 194 into ready
;; Advanced a state.
;; Ready list after queue_to_ready: 194:87 185:82
;; Ready list after ready_sort: 185:82 194:87
;; Clock 0
;; Ready list (t = 0): 185:82 194:87
;; Chosen insn : 194
;; 0--> 194 r299#4=unspec/v[0x3] 8 :slot1
;; resetting: debug insn 193
Note that there is a dependency 185->193->194. Insn 193 is a debug_insn
for var_location. When we actually get to scheduling, we seem to ignore
this dependency and put both 185 and 194 into ready state and 194 gets
picked, causing my test to go wrong.
I do not have much experience working on GCC scheduler, but i would
think there are 3 things that could be wrong here.
1. Are var_location instructions allowed to use values from unspec_volatile?
2. Should the scheduler ignore debug_insn's from its dependency computation?
3. If the scheduler does use debug_insns during dependency computation,
should it not satisfy this dependency later on?
I will try to fix this problem, but any pointers on this will be greatly
appreciated.
Thanks
Hari