> From: Segher Boessenkool > > Ah. Is there a PR for it yet? Please open one, if not. >
Yes, PR79150. I got carried away with the mailing and forgot about the PR, sorry. I have updated the PR thread with all of the things we've discussed in this thread (and some more). Let's continue this discussion over there. > > So this is generated during expand? I don't see how it ends up on an > edge. > Yes, everything is happening during expand. I tried to explain some of this in my update to the PR thread. > > In some cases there will be no loop, > > some cases there will be a loop ending with the conditional jump and > > some cases will have a loop and other instructions after the conditional > > jump. The 1st and 3rd form will get through the logic in > > commit_one_edge_insertion (albeit that the 3rd form will have incorrect > > cfg actually) but the 2nd form is rejected because of ending with a jump. > > You can easily turn the 2nd form into the 3rd by emitting some no-op > instruction last. If you can live with 3rd for GCC 7, that may be a > good solution for now. > This is a good point, but I don't know if it's the right solution. > > Other than coping with the potential for sub blocks here or letting them > > through and leaving later code to split the blocks then I see no other > > way forward. I agree it should be possible to process just the blocks > > with jump instructions in the middle and that is actually going to be > > exactly one block in this case. I don't know if updating the CFG while > > edges are being iterated on in commit_edge_insertions is safe though > > and am somewhat out of my comfort zone in general! > > Yeah I'm really not seeing where/when your movmem is emitted. > It is emitted through emit_partition_copy in insert_partition_copy_on_edge (gcc/tree-outof-ssa.c:261). Regards, Toma
