[Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation
Thu Nov 12 19:40:00 GMT 2015
On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law <email@example.com> wrote:
>On 11/12/2015 10:05 AM, Jeff Law wrote:
>>> But IIRC you mentioned it should enable vectorization or so? In
>>> 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.
>> 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
>> making the modifications necessary to handle simple latches may in
>> make the path splitting code play better with if-conversion and
>> vectorization and avoid creation of multi-latch loops. At least
>> 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
>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)
More information about the Gcc-patches