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

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 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.


On Mon, Apr 24, 2017 at 1:17 PM, Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +CC llvm-dev again!
>
> > On Apr 24, 2017, at 12:46 AM, Max Muster <olimex5812 at
gmail.com> wrote:
> >
> > Hi Matthias,
> >
> > thanks for your answer.
> >
> > The reason it would be useful for me is that I am inserting a basic
> block at IR level as part of a function pass.
> > However, LLVM's optimization passes are clever enough to optimize
my
> inserted code at IR level.
> Of course a compiler is only concerned about the observable effects of a
> program. Whether there is an extra block or not is not considered part of
> that. You should probably reconsider what you actually want here. We also
> cannot really help you with the information given so far, I am pretty sure
> you have higher goals than just keeping a basic block (otherwise you could
> just stop the compiler after your pass and the block would stay :)
>
> >
> > Are there other possibilities to avoid optimization at certain parts
of
> IR code?
> Add some instructions triggering observable effects. Typical examples for
> "tricking" optimizers would be volatile loads or volatile asm
blocks
> (possibly without actual instructions inside).
>
> - Matthias
> _______________________________________________
> 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/d3ca427f/attachment.html>

> On Apr 24, 2017, at 10:23 AM, David Jones <djones at xtreme-eda.com>
wrote:
> 
> How do you disable optimization for a function?
There is the optnone attribute (see
http://llvm.org/docs/LangRef.html#function-attributes
<http://llvm.org/docs/LangRef.html#function-attributes> ). Passes will
skip functions marked with that unless they are essential for code generation.

- Matthias

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

On Mon, Apr 24, 2017 at 10:23 AM, David Jones via llvm-dev <
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/06c9015b/attachment.html>

> 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>