llvm dev - Apr 2017 - llvm-dev Digest, Vol 154, Issue 83

>
> Date: Mon, 24 Apr 2017 19:59:07 -0700
> From: Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org>
> To: Joerg Sonnenberger <joerg at bec.de>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Disable optimization on basic block level
> Message-ID: <7F0A68C2-BE13-449D-B6BE-3D3251FCE607 at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
>
> > 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
>
>
We generate C++ simulations of Verilog hardware definitions and it's not
uncommon to end up with basic blocks containing multi-megabytes of source
code, taking an hour or more to compile. If we can partition the circuit
into separate components so the total amount of source code is the same,
but it's spread over multiple compilation units, we can reduce the compile
time by a factor of four for the largest designs.

I agree this is a very special case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/c0370020/attachment.html>