1 |
On Sat, Apr 26, 2014 at 10:37 PM, "C. Bergström" |
2 |
<cbergstrom@×××××××××.com> wrote: |
3 |
> #2 The only reference to anything which the compiler could impact is |
4 |
> "Use Boyer-Moore (and unroll its inner loop a few times)." Finding out which |
5 |
> flag controls that for ${CC} would have some importance. It's almost |
6 |
> certainly combined with -O3 and or some standalone loop related |
7 |
> optimization. (Nothing depending on LTO). If they were really clever or |
8 |
> determined - there's probably a few GCC or other pragma which could give a |
9 |
> hint about unrolling. |
10 |
|
11 |
So, I'll certainly agree that package-specific CFLAG tuning will |
12 |
always be superior to just setting some flag at the system level and |
13 |
walking away. |
14 |
|
15 |
And yet, in the same paragraph you mention -O3, which is tantamount to |
16 |
just setting a flag and walking away. That turns on 14 things you |
17 |
probably don't really need. |
18 |
|
19 |
I run -flto at the system level since in my experience it only causes |
20 |
problems with a handful of packages, and when it does provide a |
21 |
benefit I get it. For the most part it just means my compiles at 2AM |
22 |
take longer, and a bit more RAM, neither of which are a concern. If I |
23 |
do run into a bug, that is just an opportunity to log it and |
24 |
contribute (though to date I haven't been submitting -flto issues as |
25 |
bugs as it is still a bit new). |
26 |
|
27 |
I think LTO is becoming mainstream-enough that we should consider it |
28 |
supported in the sense that packages should filter it if it is known |
29 |
not to work. We certainly do that with things like -O2/3/s if they |
30 |
don't work. However, it still should be considered a somewhat |
31 |
experimental flag and enabling it will involve bumps. Also, it will |
32 |
always involve a RAM tradeoff, so there may be cases where it isn't |
33 |
filtered because it does work just fine, but it won't work for your |
34 |
system with 4GB of RAM (or 8, or 16 even). If maintainers want to add |
35 |
logic to test before building (as is sometimes done for /var/tmp with |
36 |
very large packages) they are welcome to do so, but I think that is |
37 |
going above-and-beyond. |
38 |
|
39 |
Rich |