From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: Jan Hubicka Cc: gcc-patches@gcc.gnu.org, patches@x86-64.org, gcc@gcc.gnu.org Subject: Re: RFC: BB duplication code Date: Wed, 22 Aug 2001 13:04:00 -0000 Message-id: <20010822130404.K29601@redhat.com> References: <20010822202900.D30704@atrey.karlin.mff.cuni.cz> <20010822121440.H29601@redhat.com> <20010822212756.G30704@atrey.karlin.mff.cuni.cz> X-SW-Source: 2001-08/msg01089.html On Wed, Aug 22, 2001 at 09:27:56PM +0200, Jan Hubicka wrote: > But this has problem of tracking down instruction calculaitng the value. Yep. I have no good idea how so solve that. > Sane way is to strip them. This works for superblock formation/loop peeling > as it usually don't want to duplicate whole loop. > But if I do, I lose the information. I'd say strip the loop notes. You don't really lose any information, in that correct information can always be obtained from the shape of the CFG, via flow_loop_nodes_find. > LOOP notes are not problem as we should move away from them and > their absence does not harm, but what about BLOCK_BEG/BLOCK_END? BLOCK_BEG/END must be properly duplicated for debug info to be correct. > It is, but I need to understand how and see if it still works with presence > of duplicated BB - OK, I will try to investigate this futher. It should. The reorder_blocks (bad name) function is also used for loop unrolling, which does duplication. Additionally, when bb-reorder moves two blocks that shared a BLOCK_BEG/END, duplicates are created. > So open is tablejumps - I suggest go initialy by prohibiting duplication. Seems good. > Later we may want with some conservative way - in case we will find the > instruciton taking CODE_LABEL of ADDR_VEC as argument we will allow > duplication otherwise we won't. Careful, if the target uses a pc-relative load, there may be no such instruction. Which is actually ideal for you. The best way would be to search the dominator tree for the insn that loads the label. What to do when you find it is somewhat complicated. It's not impossible that the entire table index, load, and decode could have been hoisted. There are probably simple cases that can be handled easily, but you'll probably always have to be able to cancel the duplication. r~