build gcc with lto support

[nerdralph]

The included gcc wasn't built with the linker plugin, so enabling link-time optimization (-flto) fails.
dlopen:'.../arduino-1.6.1/hardware/tools/esp8266/xtensa-lx106-elf/bin/../libexec/gcc/xtensa-lx106-elf/4.8.2/liblto_plugin-0.dll': The specified module could not be found.
Lto not only reduces code size, it can significantly improve performance by doing constant folding for function calls like digitalWrite.
http://nerdralph.blogspot.ca/2014/04/gcc-link-time-optimization-can-fix-bad.html

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rogerclarkmelbourne]

I think there is also an issue with the way gcc was compiled, so that the libiconv-2.dll, is required to be in the root of the Arduino IDE

This would prevent the repo being deployed by the new Boards Manager in IDE 1.6.2 or newer

Edit. libicon-v.dll problem still exists.

This should be fixed at the same time if possible.

[igrr]

Yes, thanks, looks like there are currently 3 issues that need to go into the toolchain:

• this one, adding lto support
• the dependency on libiconv
• need to rebuild ulibc without malloc and free

For Windows I used this build script:
https://gist.github.com/fpoussin/7ae55b5a5bd9a28ce21d

For Linux and Mac I used crosstool-NG (branch lx106-g++).

@nerdralph what options do we need to pass to build gcc with lto support?

[rogerclarkmelbourne]

Ivan,

Did you manage to fix the libiconv-2 dependency issue ?

PS. How did you run the script under windows Mingw?

[igrr]

No I didn't have a chance yet — I'm running OS X and for all the Windows stuff I have use my old laptop which I usually can access on weekends.

For the build, yes, I did use mingw.

[rogerclarkmelbourne]

OK
No worries
Thanks
Roger

[nerdralph]

It was a lot of work to figure out lto support for avr-gcc, so I imagine it
won't be any easier for the lx106. From what I recall, it depended not
only on enabling a configure option, but also on the "gold" linker plugin
version.
Right now I'm trying to figure out the lx106 instruction set including
which are 16/24 bit so I can write some code in hand tuned asm. After that
I'll look at the lto build if nobody figures it out in the meantime.
Ideally the expressif folks should release a new sdk with GCC 4.9.2 and
working lto.
On Apr 1, 2015 3:34 AM, "Ivan Grokhotkov" notifications@github.com wrote:

Yes, thanks, looks like there are currently 3 issues that need to go into
the toolchain:

• this one, adding lto support
• the dependency on libiconv
  https://github.com/rogerclarkmelbourne/arduino-esp8266/issues/2
• need to rebuild ulibc without malloc and free
  libc-provided malloc and free need to be replaced by os_malloc and os_free #11

For Windows I used this build script:
[https://gist.github.com/fpoussin/7ae55b5a5bd9a28ce21d]

For Linux and Mac I used crosstool-NG (branch lx106-g++).

@nerdralph https://github.com/nerdralph what options do we need to pass
to build gcc with lto support?

Reply to this email directly or view it on GitHub
#23 (comment).

[rogerclarkmelbourne]

Ivan

I've installed MinGW on my Windows machine, and I'm going to build (well I'm building) the using the script you linked to.

Do you have any idea's why we have the issue with libicobv-2.dll ?

I presume its a path issue?

The other version of the Xtensia compiler didn't have that issue, but I know the build switches were incorrect.

I presume the build.sh you linked to does build with the correct switches ?

I also presume it must be downloading a config file where somehow libiconv-2.dll path can be referenced ?

Anyway, I better leave it compiling, as I expect it may take several hours (or I can leave it on all night if necessary ;-)

Edit. I had some issues with Git not being installed by default with MinGW and have now fixed those, but I will need to try again tomorrow as its getting too late to continue tonight

If you have any tips for getting it to compile please let me know ;-)

[igrr]

There should be a way to tell gcc's configure script to link statically to libiconv. But I don't know which exact options are required for this though...

[igrr]

Perhaps this one might be useful: http://stackoverflow.com/a/14112368

[rogerclarkmelbourne]

Ivan

I've tried building on 2 different Windows 7 x 64 machines (more core i5 and one core2) and both just hang after a while in gcc :-(

This part of the script gives a warning ./ error

  find $XTDLP -maxdepth 1 -type d -name gmp-* | xargs -i mv -v {} $XTDLP/$GMP
  find $XTDLP -maxdepth 1 -type d -name mpfr-* | xargs -i mv -v {} $XTDLP/$MPFR
  find $XTDLP -maxdepth 1 -type d -name mpc-* | xargs -i mv -v {} $XTDLP/$MPC

but I think its OK, because its just a clumsy way to rename the file to what its already called (and fails on MinGW).

I guess I could try installing XP as a VM and see if it doesn't hang when I do that.
(I have an XP machine but its old and slow and doesnt have much ram so would take ages to compile I suspect)

Edit.
I just looked and Static libraries is supposed to be enabled already

--enable-static

and

--disable-shared --enable-static

are used

But perhaps not everywhere

[igrr]

Oh, right, it does hang quite a lot.
For me turning off parallel compilation helped:
JOBS=-j6 => JOBS=

[rogerclarkmelbourne]

Thanks

I changed to -j1 , and its no longer hanging

I'll see if it manages to complete a compile and then see what static link settings need to change, if any

I'll also need to do some research about Lto as recommended by @nerdralph