llvm dev - Aug 2015 - Scaling to many basic blocks

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150823/eb228cee/attachment.html>

On Sat, Aug 22, 2015 at 5:46 PM, Russell Wallace via llvm-dev <
llvm-dev at lists.llvm.org> 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?
>
I seem to recall the sanitizers hit some scaling issues with lots of small
basic blocks (with lots of variables) in the register allocator.

- David

>
> _______________________________________________
> 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/20150822/b6b90fcc/attachment.html>

You can expect the register allocator to be a hotspot during compiling such
functions where I'm assuming your basic blocks also end up having millions
of variables. I've not tried this in LLVM but in other compilers I've
used
it certainly has been an issue.

Since you mentioned automatic code generation which is also how I ended
up[1] in a similar situation I can tell you that 10,000 local variables or
whatever you're attempting can usually be solved by instead making it an
array of those things you were going to make individual variables.

[1] it was a protocol buffers like code generation scenario of a
schema that had thousands of fields (unrelated to each other) and I had to
sort of invent this arraying strategy to prevent compile times from
skyrocketing, that said the compiler at the time was using an n2 register
allocation algorithm.

On Saturday, August 22, 2015, Russell Wallace via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <
> mzolotukhin at apple.com
> <javascript:_e(%7B%7D,'cvml','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?
>

-- 
Sent from MetroMail
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150823/8f9b9abf/attachment.html>

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.

Joerg

> 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