# LTO support

- Thread: https://externals.io/message/117315
- Original archive: https://news-web.php.net/php.internals/117315
- Started by Go Kudo on 2022-03-12T18:17:35+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #117315 — Go Kudo — 2022-03-12T18:17:35+00:00

URL: https://externals.io/message/117315#117315

At present, PHP cannot be built using LTO (Link Time Optimization).

LTO is a compiler feature that can improve performance by optimizing at
link time.
Chromium is also using this feature.

https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html

The reason for the LTO failure appears to be the Zend Engine's use of GCC's
global register variables. Conversely, it is otherwise compatible with LTO.
(except: opcache).

I modified toolchain too to enable and validate LTOs outside of Zend Engine
and OPcache:

https://github.com/zeriyoshi/php-src/commit/b25c237837fec2f82d268d8dbd45ec886baf474f

I tested the following compilation options:

```
gcc: (Debian 10.2.1-6) 10.2.1 20210110
CFLAGS="-fstack-protector-strong -fpic -fpie -O3 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -pie"
$ ./sapi/cli/php ./Zend/bench.php
simple             0.010
simplecall         0.005
simpleucall        0.010
simpleudcall       0.013
mandel             0.052
mandel2            0.049
ackermann(7)       0.012
ary(50000)         0.003
ary2(50000)        0.002
ary3(2000)         0.020
fibo(30)           0.035
hash1(50000)       0.004
hash2(500)         0.004
heapsort(20000)    0.012
matrix(20)         0.012
nestedloop(12)     0.010
sieve(30)          0.006
strcat(200000)     0.002
------------------------
Total              0.261
```

vs

```
gcc: (Debian 10.2.1-6) 10.2.1 20210110
CFLAGS="-fstack-protector-strong -fpic -fpie -O3 -flto -fuse-linker-plugin
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -pie -flto -fuse-linker-plugin"
$ ./sapi/cli/php ./Zend/bench.php
simple             0.006
simplecall         0.003
simpleucall        0.010
simpleudcall       0.014
mandel             0.050
mandel2            0.049
ackermann(7)       0.012
ary(50000)         0.003
ary2(50000)        0.002
ary3(2000)         0.020
fibo(30)           0.035
hash1(50000)       0.004
hash2(500)         0.004
heapsort(20000)    0.012
matrix(20)         0.011
nestedloop(12)     0.010
sieve(30)          0.007
strcat(200000)     0.002
------------------------
Total              0.255
```

In fact, it does not seem to work very well. However, it may be effective
when large numbers of extensions are built into PHP.

Is anyone interested in supporting this?

---

## #117318 — thomas.pakkanen@posteo.de — 2022-03-12T20:05:52+00:00

URL: https://externals.io/message/117315#117318 · In reply to: #117315

> In fact, it does not seem to work very well.

Hi Go Kudo,


I read about the LTO feature from GCC in the past, and in my opinion, 
LTO works have many years of improvement in the GCC, it works pretty 
good nowadays. But programmers of Open Source projects were really 
clever the last twenty years. I read about bench tests where larger 
projects changes from normal compiling to -lto in GCC and after large 
benchmarking, they do not have much performance benefits from LTO. They 
said in these reports that mostly the bottleneck which -lto solves, were 
not existing in these projects: Developers for example move critical 
codes in the past from the .c-files into the .h-headers, so GCC can 
inline them without having such a feature like -lto. Or there use parts 
of "single-file" approaches for projects in C which have same compiling 
results as with the feature -lto.

So, I think LTO works fine now, but you need projects which have these 
kind of bottlenecks to benefit from LTO. :)


Best regards,
Thomas


ps:
Sorry, for two e-mails, Go, I was not able to press the right answer 
button in my email program. ^^


Am 12.03.2022 19:17 schrieb Go Kudo:
> At present, PHP cannot be built using LTO (Link Time Optimization).
> 
> LTO is a compiler feature that can improve performance by optimizing at
> link time.
> Chromium is also using this feature.
> 
> https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
> 
> The reason for the LTO failure appears to be the Zend Engine's use of 
> GCC's
> global register variables. Conversely, it is otherwise compatible with 
> LTO.
> (except: opcache).
> 
> I modified toolchain too to enable and validate LTOs outside of Zend 
> Engine
> and OPcache:
> 
> https://github.com/zeriyoshi/php-src/commit/b25c237837fec2f82d268d8dbd45ec886baf474f
> 
> I tested the following compilation options:
> 
> ```
> gcc: (Debian 10.2.1-6) 10.2.1 20210110
> CFLAGS="-fstack-protector-strong -fpic -fpie -O3 -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64"
> CXXFLAGS="${CFLAGS}"
> LDFLAGS="-Wl,-O1 -pie"
> $ ./sapi/cli/php ./Zend/bench.php
> simple             0.010
> simplecall         0.005
> simpleucall        0.010
> simpleudcall       0.013
> mandel             0.052
> mandel2            0.049
> ackermann(7)       0.012
> ary(50000)         0.003
> ary2(50000)        0.002
> ary3(2000)         0.020
> fibo(30)           0.035
> hash1(50000)       0.004
> hash2(500)         0.004
> heapsort(20000)    0.012
> matrix(20)         0.012
> nestedloop(12)     0.010
> sieve(30)          0.006
> strcat(200000)     0.002
> ------------------------
> Total              0.261
> ```
> 
> vs
> 
> ```
> gcc: (Debian 10.2.1-6) 10.2.1 20210110
> CFLAGS="-fstack-protector-strong -fpic -fpie -O3 -flto 
> -fuse-linker-plugin
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> CXXFLAGS="${CFLAGS}"
> LDFLAGS="-Wl,-O1 -pie -flto -fuse-linker-plugin"
> $ ./sapi/cli/php ./Zend/bench.php
> simple             0.006
> simplecall         0.003
> simpleucall        0.010
> simpleudcall       0.014
> mandel             0.050
> mandel2            0.049
> ackermann(7)       0.012
> ary(50000)         0.003
> ary2(50000)        0.002
> ary3(2000)         0.020
> fibo(30)           0.035
> hash1(50000)       0.004
> hash2(500)         0.004
> heapsort(20000)    0.012
> matrix(20)         0.011
> nestedloop(12)     0.010
> sieve(30)          0.007
> strcat(200000)     0.002
> ------------------------
> Total              0.255
> ```
> 
> In fact, it does not seem to work very well. However, it may be 
> effective
> when large numbers of extensions are built into PHP.
> 
> Is anyone interested in supporting this?