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_N13MainMenuLayer30onResolveCCB > CCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ > 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 > @_ZN13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d > 6ObjectEPKc({ > 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_N13MainMenuLayer30onResolveCCB > CCMenuItemSelectorEPN7cocos2d6ObjectEPKc({ > 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 > @_ZN13MainMenuLayer30onResolveCCBCCMenuItemSelectorEPN7cocos2d > 6ObjectEPKc({ > 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.
