[llvm-dev] Disable optimization on basic block level

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 24 19:59:07 PDT 2017

> 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

More information about the llvm-dev mailing list