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.
