<div dir="ltr">When my compiler generated LOAD/STORE instead of MEMCPY for large objects, the compiler spent a large amount of time trying to decide scheduling of the massive number of instructions that came from the load and store operations. It doesn't take a very huge number of instructions either, a couple of functions of 16000 instructions will take tens of seconds to compile - similar size code with "more dependencies" will be much faster to compile, in comparison.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2015 at 10:01, Joerg Sonnenberger via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Aug 23, 2015 at 09:53:16PM -0700, Mehdi Amini wrote:<br>
><br>
> > On Aug 23, 2015, at 11:35 AM, Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > On Sun, Aug 23, 2015 at 01:46:12AM +0100, Russell Wallace via llvm-dev wrote:<br>
> >> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <<a href="mailto:mzolotukhin@apple.com">mzolotukhin@apple.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> Hi,<br>
> >>><br>
> >>> Several passes would have troubles with such code (namely, GVN and<br>
> >>> JumpThreading).<br>
> >><br>
> >><br>
> >> Can you just choose not to run those particular passes? I suppose the big<br>
> >> problem would be if there's a problem with the code generation and related<br>
> >> stuff like instruction scheduling and register allocation - is that likely<br>
> >> to be the case?<br>
> ><br>
> > One problematic pass right now is correlated value propogation. The sad<br>
> > part is that at least from clang it can't be disabled short of -O0 :(<br>
> > I have a patch in my tree to at least be able to disable it with -mllvm<br>
> > magic, but Chandler didn't like it for the obvious reasons for in-tree.<br>
> ><br>
> > It would be really nice if someone could (finally) add the proper memory<br>
> > and compute time bounding to that pass.<br>
><br>
><br>
> Is there already a PR open on <a href="https://llvm.org/bugs/" rel="noreferrer" target="_blank">https://llvm.org/bugs/</a> ? Ideally with a pre-processed source to feed to clang to reproduce.<br>
<br>
</span>Sure, <a href="https://llvm.org/bugs/show_bug.cgi?id=10584" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=10584</a><br>
<br>
Joerg<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>