search

manuel-serrano / bigloo

a practical Scheme compiler
http://www-sop.inria.fr/indes/fp/Bigloo
Other
138 stars 19 forks source link

Changes to support using gcc's link time optimization #19

Closed donaldsonjw closed 5 years ago

donaldsonjw commented 5 years ago

The majority of the changes are minor discrepancies between types declared in the bigloo runtime c files and their uses in bigloo source file extern clauses.

The second type of changes were modifications to either prevent the inlining of procedures essential to proper operation of callcc or to address optimizations that prevented the proper operation of callcc. For the latter, this specifically refers to the use of alloca in callcc_restore_stack to grow the stack due to the recursive call being turned into a goto.

I have tested by configuring bigloo with --cflags="-flto" and --lflags="-flto", building, installing, and then building recette-static. All tests pass. This works for both gcc (8.2) and clang (7.0) on my arch linux box. Note for clang one of the error tests fails due to clang not throwing a division by zero exception for integer division by zero. Looking into this, it appears integer division by zero is undefined behavior in c and hence this permitted behavior, albeit different from gcc and icc.

As is to be expected, this greatly increases compile times and only works when doing static builds but does provide improvements in performance in some scenarios so may be useful when delivering final release builds where performance is essential.

svenha commented 5 years ago

Interesting work! Do you have any results from bglstone or similar (before and after this PR)?

donaldsonjw commented 5 years ago

I had not done a comparison of bglstone before and after the lto changes before today. I had been looking at the performance of of a personal implementation of srfi25. But on your prompting, I did so today. I have attached the results. For non-lto, I used the bigloo4.3e release, which is basically identical to master at this point, and for lto, the master branch with my changes applied. The results are very close, close enough that I would not want to claim they are significant, however the lto build is generally a bit faster. I am not too surprised by this result since the benchmarks are mostly single file programs using core language features that Bigloo already goes out of its way to make sure are compiled efficiently. I would expect lto to work better in larger programs which depend on a number of libraries where exposing the library implementations via lto would expose additional optimization opportunities.

bigloo4.3e.stat.txt bigloo_lto.stat.txt

manuel-serrano commented 5 years ago

Hi Joe,

I must that you have been very brave to have a look at the call/cc C implementation... This is a piece of code I hardly dare to change myself :-) Anyhow, thanks a lot for the fixes and improvements...

svenha commented 5 years ago

I tested the tar file bigloo4.3f-alpha29Jan19.tar.gz. Really nice work. Some more types need fixing for -flto: see compilation output for api/ssl and api/multimedia. That should be all.