public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* scheduler dependency bug in the presence of var_location and unspec_volatile
@ 2010-04-28 14:26 Hariharan
  0 siblings, 0 replies; only message in thread
From: Hariharan @ 2010-04-28 14:26 UTC (permalink / raw)
  To: gcc

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2010-04-28 13:58 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-28 14:26 scheduler dependency bug in the presence of var_location and unspec_volatile Hariharan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).