llvm-dev Digest, Vol 154, Issue 83

Date: Mon, 24 Apr 2017 19:59:07 -0700
From: Matthias Braun via llvm-dev <llvm-dev@lists.llvm.org>
To: Joerg Sonnenberger <joerg@bec.de>
Cc: llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] Disable optimization on basic block level
Message-ID: <7F0A68C2-BE13-449D-B6BE-3D3251FCE607@apple.com>
Content-Type: text/plain; CHARSET=US-ASCII

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