llvm dev - Jun 2015 - [LLVMdev] BasicAA unable to analyze recursive PHI nodes

> Not a huge change here although the numbers tend to be more on the side
> of a slowdown. This is interesting - you'd think that better alias
> analysis shouldn't have that effect. Any idea what could be causing
> this?

LLVM's alias analysis is good but not amazing.
If you improve it significantly (as you appear to have :P), you give
the compiler more freedom to do things.
What it chooses to do with that freedom  may not always be good :)

Basically, with any significant alias analysis change comes a lot of
tuning of heuristics/etc, or looking through regressions, to determine
what's going on now.  *Usually* it's "something used to not be able
to
do a ton of <whatever>, and now it can.  The cost model for
<whatever>
needs to be worked on so it doesn't go too crazy".

----- Original Message -----
> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Tobias Edler von Koch" <tobias at codeaurora.org>
> Cc: reviews+D10368+public+78f7503e373eac35 at reviews.llvm.org, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>,
> "Hal Finkel" <hfinkel at anl.gov>
> Sent: Saturday, June 20, 2015 11:55:55 AM
> Subject: Re: [LLVMdev] BasicAA unable to analyze recursive PHI nodes
> 
> > Not a huge change here although the numbers tend to be more on the
> > side
> > of a slowdown. This is interesting - you'd think that better alias
> > analysis shouldn't have that effect. Any idea what could be
causing
> > this?
> 
> 
> LLVM's alias analysis is good but not amazing.
> If you improve it significantly (as you appear to have :P), you give
> the compiler more freedom to do things.
> What it chooses to do with that freedom  may not always be good :)
> 
> Basically, with any significant alias analysis change comes a lot of
> tuning of heuristics/etc, or looking through regressions, to
> determine
> what's going on now.  *Usually* it's "something used to not be
able
> to
> do a ton of <whatever>, and now it can.  The cost model for
> <whatever>
> needs to be worked on so it doesn't go too crazy".
I agree. In the mean time, let's get this committed turned off by default.
Please update your patch so that the new behavior is controlled by some cl::opt
that is off by default. This will give us a better way to do more-extensive
benchmarking and help isolate the problems.

 -Hal
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Hi Hal, Daniel,

On Mon, 22 Jun 2015 20:45:38 -0500 Hal Finkel <hfinkel at anl.gov>
wrote:
> 
> I agree. In the mean time, let's get this committed turned off by
default. Please update your patch so that the new behavior is controlled by some
cl::opt that is off by default. This will give us a better way to do
more-extensive benchmarking and help isolate the problems.
> 
I've updated the patch and added the flag. Is this OK to go in now?
http://reviews.llvm.org/D10368

We're seeing some small degradations on Hexagon too (and that's in
simulation, so definitely not noise). At first glance it seems that the
main difference is that some loops are being replaced by memcpy/memset
calls (you'd think that's a good thing...), but I'll investigate
this
further.

Tobias

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.