llvm dev - Apr 2017 - Disable optimization on basic block level

> On Apr 24, 2017, at 11:00 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 
> 
> 
> On Mon, Apr 24, 2017 at 10:23 AM, David Jones via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> How do you disable optimization for a function?
> 
> I ask because my application often compiles machine-generated code that
results in pathological structures that take a long time to optimize, for little
benefit. As an example, if a basic block has over a million instructions in it,
then DSE can take a while, as it is O(n^2) in the number of instructions in the
block.
> 
> In a lot of cases, we'd rather just fix these optimizers.
> There is no reason, for example, for DSE to be N^2.
> 
> There are some that are not fixable, but ...
> 
>  
> In my application (at least), this block is typically executed only once at
run time, and is not part of a loop, so I really don't care about code
quality for that block.
> 
> I am able to identify some of these conditions. I would like to tell LLVM
to "not try so hard" on the pathological blocks, while keeping
optimizations active for ordinary cases.
> 
> This is a use case i believe where we'd rather integrate smart limits
into LLVM itself, rather than try to have people control it this way :)
I completely agree!

Would be cool to create a suite of extreme inputs, maybe a special llvm
test-suite module. This module would contain scripts that produce extreme inputs
(long basic blocks, deeply nested loops, utils/create_ladder_graph.py, etc.) In
fact I have a python script here as well that generates a few variations of
stuff that was interesting to scheduling algos. It would just take someone to
setup a proper test-suite and a bot for it and I'd happily contribute more
tests :)

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/fe2e1ee6/attachment.html>

On Mon, Apr 24, 2017 at 11:06:36AM -0700, Matthias Braun via llvm-dev
wrote:
> Would be cool to create a suite of extreme inputs, maybe a special llvm
> test-suite module. This module would contain scripts that produce
> extreme inputs (long basic blocks, deeply nested loops,
> utils/create_ladder_graph.py, etc.) In fact I have a python script here
> as well that generates a few variations of stuff that was interesting
> to scheduling algos. It would just take someone to setup a proper
> test-suite and a bot for it and I'd happily contribute more tests :)
Well, I find limited motivation to "optimise" the compiler for
artifical
code. Trying to identify real world code that triggers expensive
behavior is a much more useful exercise, IMO.

Joerg

It's not "artificial" code. It's real-world code for real
applications,
generated by scripted code generators.

An example would be a very large Yacc/Bison grammar with many actions
inside the user-action switch statement.

On Mon, Apr 24, 2017 at 8:30 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Apr 24, 2017 at 11:06:36AM -0700, Matthias Braun via llvm-dev
> wrote:
> > Would be cool to create a suite of extreme inputs, maybe a special
llvm
> > test-suite module. This module would contain scripts that produce
> > extreme inputs (long basic blocks, deeply nested loops,
> > utils/create_ladder_graph.py, etc.) In fact I have a python script
here
> > as well that generates a few variations of stuff that was interesting
> > to scheduling algos. It would just take someone to setup a proper
> > test-suite and a bot for it and I'd happily contribute more tests
:)
>
> Well, I find limited motivation to "optimise" the compiler for
artifical
> code. Trying to identify real world code that triggers expensive
> behavior is a much more useful exercise, IMO.
>
> 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/20170424/28c10f07/attachment.html>

> On Apr 24, 2017, at 5:30 PM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Mon, Apr 24, 2017 at 11:06:36AM -0700, Matthias Braun via llvm-dev
wrote:
>> Would be cool to create a suite of extreme inputs, maybe a special llvm
>> test-suite module. This module would contain scripts that produce
>> extreme inputs (long basic blocks, deeply nested loops,
>> utils/create_ladder_graph.py, etc.) In fact I have a python script here
>> as well that generates a few variations of stuff that was interesting
>> to scheduling algos. It would just take someone to setup a proper
>> test-suite and a bot for it and I'd happily contribute more tests
:)
> 
> Well, I find limited motivation to "optimise" the compiler for
artifical
> code. Trying to identify real world code that triggers expensive
> behavior is a much more useful exercise, IMO.
Well my practical experience so far has been that the function size for most
compiler inputs stays at a reasonable/smallish compared to how much memory most
computers have. I assume the humans that write that code can only handle a
per-function complexity up to a certain level.

But then there is this really small percentage of users that have written a code
generator and they typically don't care anymore about things like block
sizes, function length or loop nesting depths. We certainly fix a handful of
bugs every year... While these are not the interesting cases to optimize, I
think that a good quality compiler should at least handle them in "n log
n"/"n^2" time (the cases that end up in bug reports are usually
worse than quadratic). Catching the problems before releasing a compiler into
the wild would be worthwhile.

- Matthias