[llvm-dev] llvm (the middle-end) is getting slower, December edition

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 22 02:18:56 PST 2016


On Wed, Dec 21, 2016 at 2:57 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> On 12/21/2016 04:40 PM, Mehdi Amini wrote:
>
>
> On Dec 21, 2016, at 1:57 PM, Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
>
> On 12/21/2016 03:36 PM, Sanjay Patel via llvm-dev wrote:
>
> I would have replied to this thread sooner, but I was busy adding more
> instcombines. :)
>
> The motivation for r289855 is in the commit msg (I'm out of the office and
> can't look things up conveniently). Feel free to revert that and the follow
> ups, however, if that patch caused a noticeable slowdown, then it suggests
> we have a bigger problem?...that's a simple matcher (no value tracking
> required).
>
>
> I'd recommend against reverting this until we understand more about the
> problem.
>
>
> I tend to agree, but I’d also like that we get better understanding before
> 4.0 branches.
>
> This is not a critical compile-time regression,
>
>
> I didn’t see in this thread a mention about how much alone this is causing?
> The regression mentioned by Davide (20%) seems critical to me.
>
> Maybe I misread this. I thought it was much smaller. We should double-check
> the data too. If this one commit is responsible for a 20% compile-time
> regression, that is indeed serious.
>

Sorry if it wasn't clear, but this is not really responsible for the
whole regression. When I said "I can confirm this regresses", I meant
that this regressed by a certain amount on one of my testcases. In
particular, the two revisions together accounted for about 2% in
compile time. So, yeah, probably not worth reverting but still a
couple of revisions to keep in mind for the future.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare


More information about the llvm-dev mailing list