| 1 |
Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> Dnia 2014-04-22, o godz. 08:45:31 |
| 4 |
> Martin Vaeth <martin@×××××.de> napisa=B3(a): |
| 5 |
> |
| 6 |
>> On the other hand, if upstream tests and supports LTO, it should |
| 7 |
>> be communicated to the user somehow that this is the case. |
| 8 |
>> The same dilemma applies to some other CFLAGS which should not be |
| 9 |
>> used in general but only if the code is written for them. |
| 10 |
> |
| 11 |
> Why do you believe that LTO 'should not be used in general'? |
| 12 |
|
| 13 |
In the last sentence, I did not have LTO in mind but things |
| 14 |
like -fmerge-all-constants -fnothrow-opt -fno-enforce-eh-specs |
| 15 |
or -fno-common. The latter is perhaps again a bit similar to LTO: |
| 16 |
|
| 17 |
> As far as I understand, the LTO concept is suited well for most |
| 18 |
> programs |
| 19 |
|
| 20 |
For programs yes, but if libraries are involved often not: |
| 21 |
Experience shows that most packages which provide or use |
| 22 |
(internally) libraries break with LTO if upstream does |
| 23 |
not care about. |
| 24 |
In particular, unless gold linker is expected (which unfortunately |
| 25 |
cannot be so easily changed locally for a package and which |
| 26 |
causes other problems if used system wide), it can make sense |
| 27 |
to compile only certain parts of the package with LTO |
| 28 |
(e.g. the main binary). |
| 29 |
That's why it can make sense to let the package care about |
| 30 |
the -flto CFLAG. |
| 31 |
|
| 32 |
> (+ the usual limitations like memory). |
| 33 |
|
| 34 |
not to forget compilation time which increases by |
| 35 |
the remarkable factor 2, at least (unless optimized for lto |
| 36 |
with e.g. -fno-fat-lto-objects). |
Archives