This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



-----Original Message-----
From: Jeff Law [mailto:law@redhat.com] 
Sent: Friday, November 13, 2015 3:28 AM
To: Richard Biener
Cc: Ajit Kumar Agarwal; GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

On 11/12/2015 11:32 AM, Jeff Law 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.

Hello Jeff:
>>So here's what I'm working with.  It runs after the vectorizer now.

>>Ajit, if you could benchmark this it would be greatly appreciated.  I know you saw significant improvements on one or more benchmarks in the past.  It'd be good to know that the >>updated placement of the pass doesn't invalidate the gains you saw.

>>With the updated pass placement, we don't have to worry about switching the pass on/off based on whether or not the vectorizer & if-conversion are enabled.  So that hackery is gone.

>>I think I've beefed up the test to identify the diamond patterns we want so that it's stricter in what we accept.  The call to ignore_bb_p is a part of that test so that we're actually looking at >>the right block in a world where we're doing this transformation with simple latches.

>>I've also put a graphical comment before perform_path_splitting which hopefully shows the CFG transformation we're making a bit clearer.

>>This bootstraps and regression tests cleanly on x86_64-linux-gnu.

Thank you for the inputs. I will build the compiler and run SPEC CPU 2000 benchmarks for X86 target and respond back as soon as run is done.
I will also run  the EEMBC/Mibench benchmarks for Microblaze target.
 
Would let you know the results at the earliest.

Thanks & Regards
Ajit


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]