Just to be sure, I use emscripten-fastcomp/bin/clang, and emscripten-fastcomp/bin/clang++ to compile my sources
2017-07-13 13:13 GMT+07:00 Александр Гурьянов <[email protected]>: > *compiled > > 2017-07-13 13:12 GMT+07:00 Александр Гурьянов <[email protected]>: >> Wow, great :) I don't know that I can compile native builds with >> fastcomp compiler. >> >> Btw, I've compilted my sources with same emscripten-fastcomp compiler, >> with -O3 flag and game just run fine (abort() does not happen). >> I should try to prepare minimal testcase. >> >> 2017-07-13 6:36 GMT+07:00 Alon Zakai <[email protected]>: >>> Hard to understand what's going wrong here. I suggest trying to make a fully >>> standalone testcase, that hopefully won't need much code from those headers, >>> and that is buildable and runnable locally. >>> >>> Another thing you might try is to build natively with the exact same >>> compiler (i.e., use clang/clang++ from emscripten's fastcomp) and see if the >>> problem occurs there. A pure LLVM issue would show up there, and you can >>> then see if it's a known LLVM issue. >>> >>> On Wed, Jul 12, 2017 at 10:37 AM, Александр Гурьянов <[email protected]> >>> wrote: >>>> >>>> Ok, I just make a little test, and compare ll output of two >>>> optimizations levels (--llvm-opts 1 vs --llvm-opts2). The source is >>>> very small, and contains only one function >>>> onResolveCCBCCMenuItemSelector. ll also small: >>>> >>>> good.ll: >>>> ; Function Attrs: noinline nounwind >>>> define void >>>> @_ZThn252_N13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ >>>> i32, i32 }* noalias nocapture sret, %class.MainMenuLayer* nocapture >>>> readnone, %"class.cocos2d::Object"* nocapture readnone, i8* nocapture >>>> readonly) unnamed_addr #0 { >>>> %5 = alloca { i32, i32 }, align 4 >>>> tail call void >>>> >>>> @_ZN13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ >>>> i32, i32 }* nonnull sret %5, %class.MainMenuLayer* undef, >>>> %"class.cocos2d::Object"* undef, i8* %3) >>>> %.fca.0.gep = getelementptr inbounds { i32, i32 }, { i32, i32 }* %5, >>>> i32 0, i32 0 >>>> %.fca.0.load = load i32, i32* %.fca.0.gep, align 4 >>>> %.fca.1.gep = getelementptr inbounds { i32, i32 }, { i32, i32 }* %5, >>>> i32 0, i32 1 >>>> %.fca.1.load = load i32, i32* %.fca.1.gep, align 4 >>>> %.repack = getelementptr inbounds { i32, i32 }, { i32, i32 }* %0, i32 0, >>>> i32 0 >>>> store i32 %.fca.0.load, i32* %.repack, align 4 >>>> %.repack9 = getelementptr inbounds { i32, i32 }, { i32, i32 }* %0, >>>> i32 0, i32 1 >>>> store i32 %.fca.1.load, i32* %.repack9, align 4 >>>> ret void >>>> } >>>> >>>> bad.ll: >>>> ; Function Attrs: noinline nounwind >>>> define void >>>> @_ZThn252_N13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ >>>> i32, i32 }* noalias nocapture sret, %class.MainMenuLayer* nocapture >>>> readnone, %"class.cocos2d::Object"* nocapture readnone, i8* nocapture >>>> readonly) unnamed_addr #0 { >>>> %5 = alloca { i32, i32 }, align 4 >>>> tail call void >>>> >>>> @_ZN13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ >>>> i32, i32 }* nonnull sret %5, %class.MainMenuLayer* undef, >>>> %"class.cocos2d::Object"* undef, i8* %3) >>>> ret void >>>> } >>>> >>>> >>>> So there is only one difference, good.ll contains this between tail and >>>> ret: >>>> %.fca.0.gep = getelementptr inbounds { i32, i32 }, { i32, i32 }* %5, >>>> i32 0, i32 0 >>>> %.fca.0.load = load i32, i32* %.fca.0.gep, align 4 >>>> %.fca.1.gep = getelementptr inbounds { i32, i32 }, { i32, i32 }* %5, >>>> i32 0, i32 1 >>>> %.fca.1.load = load i32, i32* %.fca.1.gep, align 4 >>>> %.repack = getelementptr inbounds { i32, i32 }, { i32, i32 }* %0, i32 0, >>>> i32 0 >>>> store i32 %.fca.0.load, i32* %.repack, align 4 >>>> %.repack9 = getelementptr inbounds { i32, i32 }, { i32, i32 }* %0, >>>> i32 0, i32 1 >>>> store i32 %.fca.1.load, i32* %.repack9, align 4 >>>> >>>> Is it ok, is it enough to fill issue? I can make testcase, but I wan't >>>> show you headers of this cpp file (because of NDA), may be I can pack >>>> headers in some way. >>>> >>>> P.S. This is archive with ll files, and my source file. >>>> >>>> https://drive.google.com/file/d/0B28AXjYMDNZsRi01Z2trUy1aU0U/view?usp=sharing >>>> >>>> 2017-07-12 12:16 GMT+07:00 Александр Гурьянов <[email protected]>: >>>> > I've checked, INLINING_LIMIT=1 wan't helps. May be I can see >>>> > something in intermediate object file (bc)? >>>> > >>>> > 2017-07-11 20:04 GMT+07:00 Jukka Jylänki <[email protected]>: >>>> >> There have been reports about -llvm-opts being buggy in the past, >>>> >> especially in combination with inlining. You could try to see if an >>>> >> earlier version of Emscripten might work, to see if this is a >>>> >> regression somewhere. Also, the linker flag -s INLINING_LIMIT=1 has >>>> >> been observed to affect -llvm-opts related code. >>>> >> >>>> >> 2017-07-11 13:32 GMT+03:00 caiiiycuk <[email protected]>: >>>> >>> Hi. I've working on big game based on cocos2d engine. I think that I >>>> >>> found >>>> >>> optimization bug, but I can't found test case yet. When I try to >>>> >>> extract >>>> >>> problem code to new project it's works. I think that bug is not in >>>> >>> game, >>>> >>> because I've checked all memory access with vallgrind and it's ok, >>>> >>> moreover >>>> >>> ASSERTION=2, SAFE_HEAP=1 also does not reports any error. So, I try to >>>> >>> explain what code does. Basically cocos2d have node loader, that parse >>>> >>> files, and build game gui. During this process node loader assing >>>> >>> callbacks >>>> >>> for gui elements, for example it set handlers for onclick events and >>>> >>> etc. >>>> >>> >>>> >>> Target is gui element (like menu button), selectorName is name of >>>> >>> callback, >>>> >>> and onResolveCCBCCMenuItemSelector should find callback: >>>> >>> //... >>>> >>> CCBSelectorResolver * targetAsCCBSelectorResolver >>>> >>> = >>>> >>> dynamic_cast<CCBSelectorResolver *>(target); >>>> >>> >>>> >>> if(targetAsCCBSelectorResolver != NULL) { >>>> >>> selMenuHandler = >>>> >>> targetAsCCBSelectorResolver->onResolveCCBCCMenuItemSelector(target, >>>> >>> selectorName.c_str()); >>>> >>> } >>>> >>> >>>> >>> if(selMenuHandler == 0) { >>>> >>> CCLOG("Skipping selector '%s' since no >>>> >>> CCBSelectorResolver is present.", selectorName.c_str()); >>>> >>> abort(); // BAD CASE >>>> >>> } else { >>>> >>> //... >>>> >>> >>>> >>> >>>> >>> onResolveCCBCCMenuItemSelector implementation is simple, just compare >>>> >>> strings and return pointer: >>>> >>> >>>> >>> SEL_MenuHandler MainMenuLayer::onResolveCCBCCMenuItemSelector(CCObject >>>> >>> * >>>> >>> pTarget, const char* pSelectorName) >>>> >>> { >>>> >>> if (strcmp(pSelectorName, "achievementsPressed:") == 0) >>>> >>> { >>>> >>> return (SEL_MenuHandler) MainMenuLayer::achievementsPressed; >>>> >>> } >>>> >>> else if (strcmp(pSelectorName, "missionsPressed:") == 0) >>>> >>> { >>>> >>> return (SEL_MenuHandler) MainMenuLayer::missionsPressed; >>>> >>> } >>>> >>> else if (strcmp(pSelectorName, "clonesPressed:") == 0) >>>> >>> { >>>> >>> return (SEL_MenuHandler) MainMenuLayer::clonesPressed; >>>> >>> } >>>> >>> ... >>>> >>> return 0; >>>> >>> } >>>> >>> >>>> >>> In normal execution abort() never calls, but if I optimize game with >>>> >>> -O2, >>>> >>> abort() happens. But even in -O2 onResolveCCBCCMenuItemSelector >>>> >>> returns non >>>> >>> zero value (pointer) (I've checked with printf before return), but >>>> >>> abort() >>>> >>> happens! >>>> >>> To solve this, I move all onResolveCCBCCMenuItemSelector impls into >>>> >>> handlers.cpp, and compile it with -O3 --js-opts 1 --llvm-opts 1 and >>>> >>> game >>>> >>> works fine, but if I switch optimizations to --lvm-opts 2 abort >>>> >>> occurs. >>>> >>> How I can figure out what happens? handlers.cpp is very small file, >>>> >>> with >>>> >>> couple of funcs, but if I optimize it game wan't work. >>>> >>> >>>> >>> Thank you! >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> 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. >>> >>> >>> -- >>> 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.
