<div dir="ltr"><div>My gambit is configured with  --enable-single-host --enable-c-opt --enable-gcc-opts.<br></div><div>I have 8G on my current laptop, but I run without a swap; the death occurs at around 6G. <br>It's not only the memory usage though, it takes forever too. clang on travis didn't OOM, but it took 15min on the file.<br></div><div><br></div><div>I think it might be a case of really bad interaction between the various optimizers in the 3 compilers involved. The gerbil emitted code is already heavily optimized to perform match tree linearization (I have a shiny new optimizer that optimizes match and syntax- case expansions).<br></div><div>That means you can't reasonably inline anything other than single use procedures within the optimized blocks.<br></div><div><br></div><div>-- vyzo<br></div><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 19, 2018 at 8:41 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The default inlining-limit is 350, so the expansion from 100 is quite possible.<br>
<br>
But the problem here is that gcc chokes on the compilation of the C file.  So… what are the compilation options passed to gcc?<br>
<br>
- are you using --enable-single-host ?<br>
- are you using a higher level of optimization such as -O2 or -O3 rather than the default -O1 ?<br>
<br>
These will definitely increase the pressure on the C compiler.  Also, some versions of gcc do a better job at compiling large C files.  The file lib/_io.c in the Gambit distribution is about 90kloc and I have never gotten an OOM error from gcc while compiling it, even though I use a “make -j 8” (8 C compilations in parallel).  I do have 16 GB of RAM on my machine… how much RAM do you have on yours?<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Marc<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<br>
> On Mar 19, 2018, at 2:31 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
><br>
> It's 140kloc without the inlining declaration and just 22Kloc with the declaration.<br>
><br>
> -- vyzo<br>
><br>
> On Mon, Mar 19, 2018 at 8:27 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br>
> Out of curiosity, what is the number of LOC of C with and without the inlining-limit?<br>
><br>
> I’m just wondering if this should be classified as an issue, or if the inliner is just doing its work as expected.<br>
><br>
> Marc<br>
><br>
><br>
><br>
> > On Mar 19, 2018, at 2:23 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> ><br>
> > It seems it's the inliner going haywire -- if I add a (declare (inlining-limit 100)), then it compiles in 20s.<br>
> ><br>
> > -- vyzo<br>
> ><br>
> > On Mon, Mar 19, 2018 at 7:29 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> > The attached file results in a 140kloc monster that results in gcc dying with OOM after several minutes of effort, and I would like to understand why.<br>
> > Any ideas?<br>
> ><br>
> > -- vyzo<br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div></div></div>