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