> 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. Thanks, Mehdi
Joerg Sonnenberger via llvm-dev
2015-Aug-24 09:01 UTC
[llvm-dev] Scaling to many basic blocks
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
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>