I'm suggesting reducing the volume of debug info with any optimizations (f.e. -O2) and -g4. There's currently too much data (a 22x increase in .bc files). There are clang flags for this -flimit-debug-info. I tried passing those, but the .bc files were unchanged. It's hard to tell from disassembling the .bc files what is in the file, and what is just the verbose display of data from llvm. With relative paths and lines embedded, turning on -g4 to get to source maps shouldn't need that much more space over -g3. It feels like something is too verbose in the g4 setting.
On Sunday, February 15, 2015 at 12:21:47 PM UTC-8, Alon Zakai wrote: > > Fastcomp is the backend, "native optimizer" is something that runs after > it. We disable the latter, not the former, when using source maps. > > I think emscripten also disables debug info by default, except at -O0. > > - Alon > > > On Fri, Feb 13, 2015 at 2:50 PM, Alecazam <[email protected] <javascript:>> > wrote: > >> If emcc -g4 is using clang, then experimenting with the clang flags might >> do the trick (-gline-tables-only and/or -flimit-debug-info). It seems >> that Darwin clang defaults to disabling optimizing debug info except at >> -O0. See thread here: >> >> >> http://llvm.org/klaus/clang/commit/c44757105021d1429f9430d5ff0da45b02b9f741/ >> >> >> On Friday, February 13, 2015 at 2:30:47 PM UTC-8, Alecazam wrote: >>> >>> >>> 1. We cannot use the fast native optimizer when emitting source maps >>>>> >>>> >>> Does that mean fastcomp isn't used? I re-read about fastcomp, but there >>> wasn't any mention of source maps disabling it. Indeed turning on -g4 >>> generates 443MB of bc data, where -g3 only generates 20MB. That's a 22x >>> increase in bc data, and it's not suprising the linker slows dramatically >>> from parsing 2.2GB of data. The final js output is a few MB. >>> >>> It seems like -g3 should be most of the data needed, and there should >>> only be a small addition from adding file/line directives to the source. >>> It's not like it's copying the source into the .bc files, just a source >>> marker. We're looking at the .bc data, but it feels like there may be too >>> much data requested on the part of emcc (type info?). The linker is having >>> to toss out all this unneeded data. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
