Hi Steve,<br><br>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). <br><br>James<br><div class="gmail_quote"><div dir="ltr">On Sat, 21 Nov 2015 at 00:01, Steve King <<a href="mailto:steve@metrokings.com">steve@metrokings.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<br>
> On 19 November 2015 at 19:08, Steve King via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> Does the community have bots or humans tracking code size for -Os<br>
>> builds?<br>
><br>
> Hi Steve,<br>
><br>
> I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do<br>
> track performance every release, but not code size at -Os.<br>
><br>
>>  I've noticed troubling regressions lately.  Sometime near Nov<br>
>> 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for<br>
>> i586.  That's ghastly.  This week, the EEMBC matrix01 workload grew by<br>
>> 5% for ARMv7m and 3% for i586.<br>
><br>
> Hum, v7M is even lower priority for me at the moment. :)<br>
><br>
> Though, I have to say, 25% is really bad. Can you bisect to see which<br>
> commit was that?<br>
<br>
Hi Renato, Thanks for advising.  The commit is:<br>
<br>
[llvm] r252152 - [SimplifyCFG] Tweak heuristic for merging conditional stores<br>
<br>
Can this be reverted until the surprising code size impact is<br>
understood?  I'm about to leave for the week, so I can't delve further<br>
anytime soon.<br>
<br>
Regards,<br>
-steve<br>
</blockquote></div>