On Wed, Jan 23, 2019 at 04:52:24PM +0300, Alexander Monakov wrote: > On Wed, 23 Jan 2019, Andrey Belevantsev wrote: > > For that, I'm not sure. Your patch will leave the tablejump unscheduled at > > all, i.e. any fields like INSN_TICK would be unfilled and thus the later > > passes like bundling on ia64 will not work. Maybe we can just stop > > tablejumps from moving within its block, Alexander? > > On the Bugzilla there's an alternative patch by Segher that adjusts the assert > to accept this situation (there's still a barrier insn after the tablejump > insn, > it's just after a jump_table_data insn rather than immediately following the > jump). That should be a better approach, and David said he was testing it. > > That said, I'm really concerned that on this testcase we should not be moving > the tablejump *at all*: we are moving it up past a 'use ax' insn (the use is > for the function's return value). So after the move the use is in an > unreachable > block, which makes no sense.
Yes, that makes no sense indeed. Is it acceptable (for performance) to simply bail out on table jumps here? > So my concern is that just fixing the assert changes the issue from the ICE > to a > (latent) wrong-code issue. > > There should have been an anti-dependence between the use and the jump. I'll > try > to investigate. Or that. Thanks! Segher
