[llvm-dev] Scaling to many basic blocks

[mats petersson via llvm-dev]

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.

On 24 August 2015 at 10:01, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sun, Aug 23, 2015 at 09:53:16PM -0700, Mehdi Amini wrote:
> >
> > > On Aug 23, 2015, at 11:35 AM, Joerg Sonnenberger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >
> > > On Sun, Aug 23, 2015 at 01:46:12AM +0100, Russell Wallace via llvm-dev
> wrote:
> > >> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <
> mzolotukhin at apple.com>
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Several passes would have troubles with such code (namely, GVN and
> > >>> JumpThreading).
> > >>
> > >>
> > >> Can you just choose not to run those particular passes? I suppose the
> big
> > >> problem would be if there's a problem with the code generation and
> related
> > >> stuff like instruction scheduling and register allocation - is that
> likely
> > >> to be the case?
> > >
> > > One problematic pass right now is correlated value propogation. The sad
> > > part is that at least from clang it can't be disabled short of -O0 :(
> > > I have a patch in my tree to at least be able to disable it with -mllvm
> > > magic, but Chandler didn't like it for the obvious reasons for in-tree.
> > >
> > > It would be really nice if someone could (finally) add the proper
> memory
> > > and compute time bounding to that pass.
> >
> >
> > Is there already a PR open on https://llvm.org/bugs/ ? Ideally with a
> pre-processed source to feed to clang to reproduce.
>
> Sure, https://llvm.org/bugs/show_bug.cgi?id=10584
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150824/e9d519b7/attachment.html>