On Wed, Apr 2, 2014 at 9:34 PM, Trevor Linton <[email protected]>wrote:
> Great, i'll be moving to incoming fairly soon to try things out on the > cutting edge. > > I've found some oddities that i'm unsure whether these are bugs, my > misunderstanding functionality/features or otherwise. > > 1. -s LINKABLE=1 increases my code size by 30%! Should be a warning about > that for larger projects ;) However it was also a source of "too many > variables" problems in Firefox. > This is expected - as in the docs, it means that we do not remove methods that are uncalled. Otherwise, LLVM can remove a lot of code that it sees is not reachable from main() or any other entry point. So make sense that code size increases. > > 2. The dreaded "warning: unresolved symbols: emscripten_gl<Legacy GL > function>" were resolved when I added -s LINKABLE=1, but now are back > (doesn't seem to affect code execution though). > > Those warnings should not show up on latest incoming. But as you say, there are just annoying, they don't cause any actual problems. > 3. -s NO_EXIT_RUNTIME produced a LLVM TRAP! I didn't chase down the stack > trace since it was a release mode but I should mention that I never > intended on running "main" so it might not be an issue? > > That might be a bug, worth rebuilding and checking where it happened. > 4. --memory-init-file 1 did cut down code and produced a ~2MB memory file, > however it also caused a LLVM TRAP. > > Same thing, we need to figure out if that is a bug or not. > 5. -s OUTLINING_LIMIT=x doesn't seem to change the code at all, no matter > what number I put in the md5 is the exact same. No file size changes, no > behavior changes, nothing.. is there a typo?.. Am I crazy?.. > > Try to run emcc -O2 -g tests/hello_malloc.cpp -s OUTLINING_LIMIT=100 That should definitely emit different code than emcc -O2 -g tests/hello_malloc.cpp > 6. --llvm-lto 1 was quite helpful, reduced 27MB to 25MB, --llvm-lto > brought it 25MB to 22MB!! In my VERY limited unit tests (~25) nothing has > changed, execution speed increased 3% as well, within a margin of error but > it seems "stablish". Since I have both a Debug and Release version I'm > thinking about blowing out the unit tests and leaving it at --llvm-lto 3, > since it came in at an all star 19MB!!! And a 6.8% increase in render > speed! Oddly enough, and i'm not joking, rendering loops are now neck to > neck with native C++ render loop performance. Is --lvm-lto 3 to unsafe to > use?.. Why? its a beautiful beacon of bountiful performance. > LLVM LTO used to be unsafe. But it is possible it is more stable now in recent LLVM. Good to know it works well on WebKit, perhaps we should consider enabling it by default (we'd need to do a lot of testing and fuzzing first). > > 7. Allowing "Memory to grow" always threw an LLVM trap, is the -s > TOTAL_MEMORY=X a cap on the memory use, or is this amount of memory > effectively grabbed for the heap when it initializes?.. I was never clear > on it and don't understand its impact to performance/init > Memory growth means that TOTAL_MEMORY is the initial size, and it can grow to unlimited size afterwards (well, until the browser/OS runs out of memory). > > 8. -s INLINING_LIMIT=1 increased my code size by 5% and didn't really help > anything that I could tell.. > > 9. I still get ASM validation errors: asm.js type error: incompatible > number of arguments (4 here vs. 3 before). Not sure if these are related to > what you fixed earlier, but the last part (1 here vs. 0 before) has now > changed to (4 here vs. 3 before), I haven't updated emcc so it must be > related to some of the compiler options I enabled/disabled. > Do you get those errors on incoming with fastcomp enabled? If so, please send the bitcode + command to run. - Alon -- 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.
