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

Reply via email to