On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 11/12/2015 10:05 AM, Jeff Law wrote: >>> But IIRC you mentioned it should enable vectorization or so? In >this >>> case >>> that's obviously too late. >> The opposite. Path splitting interferes with if-conversion & >> vectorization. Path splitting mucks up the CFG enough that >> if-conversion won't fire and as a result vectorization is inhibited. >It >> also creates multi-latch loops, which isn't a great situation either. >> >> It *may* be the case that dropping it that far down in the pipeline >and >> making the modifications necessary to handle simple latches may in >turn >> make the path splitting code play better with if-conversion and >> vectorization and avoid creation of multi-latch loops. At least >that's >> how it looks on paper when I draw out the CFG manipulations. >> >> I'll do some experiments. >It doesn't look too terrible to ravamp the recognition code to work >later in the pipeline with simple latches. Sadly that doesn't seem to >have fixed the bad interactions with if-conversion. > >*But* that does open up the possibility of moving the path splitting >pass even deeper in the pipeline -- in particular we can move it past >the vectorizer. Which is may be a win. > >So the big question is whether or not we'll still see enough benefits >from having it so late in the pipeline. It's still early enough that >we >get DOM, VRP, reassoc, forwprop, phiopt, etc. > >Ajit, I'll pass along an updated patch after doing some more testing.
BTW, if you not use loops_normal for loop init you don't get simple latches forced (and cfg-cleanup will remove them) Richard. >Jeff
