<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Date: Mon, 24 Apr 2017 19:59:07 -0700<br>
From: Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Joerg Sonnenberger <<a href="mailto:joerg@bec.de">joerg@bec.de</a>><br>
Cc: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] Disable optimization on basic block level<br>
Message-ID: <<a href="mailto:7F0A68C2-BE13-449D-B6BE-3D3251FCE607@apple.com">7F0A68C2-BE13-449D-B6BE-<wbr>3D3251FCE607@apple.com</a>><br>
Content-Type: text/plain; CHARSET=US-ASCII<br>
<br>
<br>
> On Apr 24, 2017, at 5:30 PM, Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Mon, Apr 24, 2017 at 11:06:36AM -0700, Matthias Braun via llvm-dev wrote:<br>
>> Would be cool to create a suite of extreme inputs, maybe a special llvm<br>
>> test-suite module. This module would contain scripts that produce<br>
>> extreme inputs (long basic blocks, deeply nested loops,<br>
>> utils/create_ladder_graph.py, etc.) In fact I have a python script here<br>
>> as well that generates a few variations of stuff that was interesting<br>
>> to scheduling algos. It would just take someone to setup a proper<br>
>> test-suite and a bot for it and I'd happily contribute more tests :)<br>
><br>
> Well, I find limited motivation to "optimise" the compiler for artifical<br>
> code. Trying to identify real world code that triggers expensive<br>
> behavior is a much more useful exercise, IMO.<br>
<br>
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.<br>
<br>
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.<br>
<br>
- Matthias<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>I agree this is a very special case.</div><div><br></div></div></div></div>