[llvm-dev] Disable optimization on basic block level

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 24 11:06:36 PDT 2017


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


More information about the llvm-dev mailing list