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.
