[llvm-dev] Disable optimization on basic block level

[Daniel Berlin via llvm-dev]

On Mon, Apr 24, 2017 at 7:59 PM, Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

Mostly :)
But in practice, humans end up triggering the limits most of the time, it
just takes longer.

I've rarely seen an N^3 or worse algorithm in a compiler that didn't end up
a problem over time for real code.

We aren't usually talking about things that are fundamentally impossible in
faster time bounds.
We are talking about things that we've skimped on the implementation for
various reasons (sometimes very good!) and decided not to do faster.

IE to me there is a big difference between, say, andersen's points-to,
which is N^3 worst case, but linear with good implementations in practice,
and say, "rando algorithm i came up with for DSE or something that is N^3
because i don't feel like implementing one of the good ones"
The former, yeah, we do what we can
The latter, those things tend to be the problems over time.

IE something may be better than nothing, but over time, if we don't fix it,
that something ends up very very bad.

If you are doing a thing, and it's a sane thing to do, and your problem is
you just have generated tooo much code for the compiler, that is important
to me.
If you are doing a thing, it's crazy, or your code generator just flat out
sucks, less important.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/97e7afa9/attachment.html>