On 2/18/19 10:41 AM, Alexander Monakov wrote: > On Mon, 18 Feb 2019, Aaron Sawdey wrote: > >> The code in emit_case_dispatch_table() will very clearly always emit >> branch/label/jumptable_data/barrier >> so this does need to be handled. So, yes tablejump always looks like this, >> and also yes it seems to be >> ripe ground for logic bugs, we have 88308, 88347, 88423 all related to it. >> >> In the long term it might be nice to use a general mechanism >> (SCHED_GROUP_P?) for handling the label and jump >> table data that follow a case branch using jump table. >> >> But for now in stage 4, I think the right way to fix this is with the patch >> that Segher posted earlier. >> If regtest passes (x86_64 and ppc64/ppc32), ok for trunk? > > How making an assert more permissive is "the right way" here? > As already mentioned, without the assert we'd move a USE of the register with > function return value to an unreachable block, which would be incorrect. > > Do you anticipate issues with the sched-deps patch?
Alexander, I see you are allowing it to see the barrier as if it were right after the tablejump. Are you saying that the motion of the tablejump is happening because the scheduler does not see the barrier (because it does not follow immediately after) and thus decides it can move instructions to the other side of the tablejump? I agree that is incorrect and is asking for other hidden problems. It would be nice if the tablejump, jump table label, jump table data, and barrier were all one indivisible unit somehow. In the meantime, can someone approve Alexander's patch? Thanks, Aaron -- Aaron Sawdey, Ph.D. acsaw...@linux.vnet.ibm.com 050-2/C113 (507) 253-7520 home: 507/263-0782 IBM Linux Technology Center - PPC Toolchain
