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]> 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].
> 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