To reduce the link times and memory needed (for me, 2GB and 300s link at 
-g4, vs 300MB and 30s at -g3), these were the possible scenarios we 
discussed at GDC.

A.  Eliminate type info from the .bc files on compile (saves disk space), 
linker just works with what it gets, compiles might be faster
  or 
B.  Strip the type info out of the .bc files at link time with a post load 
pass.  Can perform all of this at the linker level, and eventually do 
something with type info in bc files.

C.  Additional link and/or compile option to not write out the debug info 
for stl classes.  These are prevalent template types that get replicated 
for each type - bloating the .bc files.


In addition, getting unmangled names in the profiling/debugger would 
complete Emscripten C++ support.

Get Firefox and Chrome (and other browsers to follow) to unmangle names in 
the stack traces and profiles when running asm.js.  I already have 
DEMANGLE_SUPPORT enabled for logged stack traces and that works well.


On Tuesday, February 17, 2015 at 11:52:39 AM UTC-8, Alon Zakai wrote:
>
> You can disassemble LLVM bitcode with llvm-dis, might help figure out 
> which flags can help here.
>
> - Alon
>
>
> On Sun, Feb 15, 2015 at 3:55 PM, Alecazam <[email protected] <javascript:>> 
> wrote:
>
>> 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]> 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/c44757105021d1429f9430d5ff0da4
>>>> 5b02b9f741/
>>>>
>>>>
>>>> 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].
>>>> 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] <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.

Reply via email to