| 1 |
Dnia 2014-04-22, o godz. 08:45:31 |
| 2 |
Martin Vaeth <martin@×××××.de> napisał(a): |
| 3 |
|
| 4 |
> On the other hand, if upstream tests and supports LTO, it should |
| 5 |
> be communicated to the user somehow that this is the case. |
| 6 |
> The same dilemma applies to some other CFLAGS which should not be |
| 7 |
> used in general but only if the code is written for them. |
| 8 |
|
| 9 |
Why do you believe that LTO 'should not be used in general'? |
| 10 |
|
| 11 |
As far as I understand, the LTO concept is suited well for most |
| 12 |
programs, though the results can vary. I agree that in the early stage |
| 13 |
many packages may be unhappy about it but as far as I understand, once |
| 14 |
it is more widespread only a few corner cases would be unsuited for LTO |
| 15 |
(+ the usual limitations like memory). |
| 16 |
|
| 17 |
That being the case, I'd feel it be more correct for LTO to disabled |
| 18 |
by default and enabled via CFLAGS+LDFLAGS, with packages not supporting |
| 19 |
LTO using flag-o-matic to filter them out. |
| 20 |
|
| 21 |
Although I should note that my understanding of LTO is pretty much |
| 22 |
limited to clang's angle. I don't know if gcc doesn't behave different. |
| 23 |
|
| 24 |
-- |
| 25 |
Best regards, |
| 26 |
Michał Górny |
Archives