[llvm-dev] Recent -Os code size regressions
James Molloy via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 20 17:06:12 PST 2015
Hi,
We'd need to look precisely at what's causing the code size bloat. The
midend commit pointed out by Steve shouldn't cause bloat in and of itself -
it should reduce code size. It removes a load of stores and branches.
I know a backend change I made to ARM isn't behaving as well as it could,
and I have patches to fix that. Speculatively reverting midend patches
isn't the best way to approach this, in my opinion! :)
James
On Sat, 21 Nov 2015 at 00:50, Smith, Kevin B <kevin.b.smith at intel.com>
wrote:
> Maybe adjust this to be different for –Os, -Oz than for –O2?
>
>
>
> Kevin Smith
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *James
> Molloy via llvm-dev
> *Sent:* Friday, November 20, 2015 4:05 PM
> *To:* Steve King <steve at metrokings.com>; Renato Golin <
> renato.golin at linaro.org>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Recent -Os code size regressions
>
>
>
> Hi Steve,
>
> That commit gives significant performance improvements, so I'm not happy
> reverting it because of the code size increase. A lot of the code size
> increase is backend dependent, and I have a set of patches that improves
> the codegen drastically on ARM at least. The midend is generating better
> code, and more optimisable code (and it's about 30% more performance too).
>
> James
>
> On Sat, 21 Nov 2015 at 00:01, Steve King <steve at metrokings.com> wrote:
>
> On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
> > On 19 November 2015 at 19:08, Steve King via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> Does the community have bots or humans tracking code size for -Os
> >> builds?
> >
> > Hi Steve,
> >
> > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do
> > track performance every release, but not code size at -Os.
> >
> >> I've noticed troubling regressions lately. Sometime near Nov
> >> 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for
> >> i586. That's ghastly. This week, the EEMBC matrix01 workload grew by
> >> 5% for ARMv7m and 3% for i586.
> >
> > Hum, v7M is even lower priority for me at the moment. :)
> >
> > Though, I have to say, 25% is really bad. Can you bisect to see which
> > commit was that?
>
> Hi Renato, Thanks for advising. The commit is:
>
> [llvm] r252152 - [SimplifyCFG] Tweak heuristic for merging conditional
> stores
>
> Can this be reverted until the surprising code size impact is
> understood? I'm about to leave for the week, so I can't delve further
> anytime soon.
>
> Regards,
> -steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151121/282a3835/attachment.html>
More information about the llvm-dev
mailing list