<div dir="ltr"><div>rL296252's  main change was to turn on anti-aliasing in the DAGCombiner. This should generally be a mild improvement to code due to the relaxed memory constraints, modulo any patterns downstream that are no longer general enough. This looks to be the case here. </div><div><br></div><div>I'm going to leave this for a little while longer to get a check that all the buildbots pass, but I'll revert this and make sure this test case looks more reasonable. </div><div><br></div><div>-Nirav</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 25, 2017 at 12:51 PM, Amaury SECHET <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>I'm working with workload where the bottleneck is cryptographic signature checks. Or, in compiler terms, most large integer operations.<br><br></div>Looking at rL296252 , the state of affair in that area degraded quite significantly, see test/CodeGen/X86/i256-add.ll for instance.<br><br></div>Is there some kind of work in progress here and it is expected to get better ? Because if not, that's a big problem. It looks like the problem is that the compiler now choose to use pushfq/popfq in some cases rather than chaining adc to propagate the carry in additions.<br><br></div>I hope this can get sorted out quickly. I'm happy to help if that is necessary.<br><br></div>Thanks,<br><br></div>Amaury SECHET<br></div>
</blockquote></div><br></div></div>