On 1/24/19 8:43 AM, Alexander Monakov wrote: > On Wed, 23 Jan 2019, Alexander Monakov wrote: > >> It appears that sched-deps tries to take notice of a barrier after a jump, >> but >> similarly to sched-ebb doesn't anticipate that for a tablejump the barrier >> will >> appear after two more insns (a code_label and a jump_table_data). >> >> If so, it needs a fixup just like the posted change for the assert. I'll >> fire up >> a bootstrap/regtest. > > Updated patch below (now taking into account that NEXT_INSN may give NULL) > passes bootstrap/regtest on x86_64, also with -fsched2-use-superblocks. > > I'm surprised to learn that a tablejump may be not the final insn in its > containing basic block. It certainly seems like a ripe ground for logic > bugs like this one. Is it really intentional? > > OK for trunk? > > Thanks. > Alexander > > PR rtl-optimization/88347 > PR rtl-optimization/88423 > * sched-deps.c (sched_analyze_insn): Take into account that for > tablejumps the barrier appears after a label and a jump_table_data. I merged this with David's new tests and committed the changes to the trunk.
THanks, Jeff
