[Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

Richard Biener richard.guenther@gmail.com
Thu Nov 12 19:40:00 GMT 2015


On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law <law@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




More information about the Gcc-patches mailing list