Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
Activity
Asuka
@Inori
@yuri91 The StructurizeCFG is not used to recover high-level structured control flow, it is designed to vectorising divergent control-flow
the main purpose of that pass is to transform a single-thread CFG to a CFG which can be execute on vectorized hardwares like GPU
Asuka
@Inori
it is used only in AMDGPU backend to generate GCN machine code, which do not need high-level structures
Asuka
@Inori
can you explain why the Stackifier willl produce labeled break/continue? is it possible to get rid of that in theory?
Asuka
@Inori
without introducing new label variables though
Yuri Iozzelli
@yuri91

I don't know for sure, but I think that you must introduce label variables.

The reason why I think that is that labeled break/continue were introduced in languages specifically to avoid providing goto, but still allow most programs to be expressed efficiently.

In particular :

In 1973, S. Rao Kosaraju proved that it's possible to avoid adding additional variables in structured programming, as long as arbitrary-depth, multi-level breaks from loops are allowed

One thing that you may try: since I suppose that you are allowed to use early return statements, you can wrap any block that needs a multi-level break into its own function, and use return instead of break. Not sure about continue but probably you can figure out something.
If this is better or worse than label variables in practice I don't know

Asuka
@Inori
well, that will make the generated code totally unreadable for some complex cases.
I'm going to first emit gotos and then eliminate them using this approach, and yes, an additional variable is needed:
Asuka
@Inori
hi, I'm trying to compile and run cheerp-compiler on windows
but it crashes on this function.
the function in problem is not always crash, it seems the iterator W and BaseClass::end() is not from one container only for sometimes.
some call stack information
Carlo Piovesan
@carlopi
can you share the testcase triggering this problem?
Asuka
@Inori
yes, this is my hello.cpp
and command line:
-cc1 -triple cheerp-leaningtech-webbrowser-genericjs -emit-llvm-bc -emit-llvm-uselists -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -fno-verbose-asm -no-integrated-as -mconstructor-aliases -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -fno-dwarf-directory-asm -v "-fcoverage-compilation-dir=D:\\PS4Dev\\Cheerp\\bin" -resource-dir "D:\\PS4Dev\\Cheerp\\lib\\clang\\14.0.0" -internal-isystem "D:\\PS4Dev\\Cheerp\\bin/../include/c++/v1" -internal-isystem "D:\\PS4Dev\\Cheerp\\lib\\clang\\14.0.0\\include" -internal-externc-isystem "D:\\PS4Dev\\Cheerp\\bin/../include" -internal-externc-isystem "D:\\PS4Dev\\Cheerp\\bin/../include/client" -O3 -fdeprecated-macro "-fdebug-compilation-dir=D:\\PS4Dev\\Cheerp\\bin" -ferror-limit 19 -fmessage-length=120 -fno-rtti -fgnuc-version=4.2.1 -fno-threadsafe-statics -fcolor-diagnostics -vectorize-loops -vectorize-slp -o "C:\\Users\\bingk\\AppData\\Local\\Temp\\hello-00d983.bc" -x c++ hello.cpp
I start it from within visual studio, and the code base is from the latest master
Asuka
@Inori
remove the debug verify doesn't help, it will crash on other code of std::deque
Carlo Piovesan
@carlopi
I am unsure of what's going wrong, could you possibly try to compile from the command line something equivalent to:
D:\\PS4Dev\\Cheerp\\bin\\clang++ hello.cpp -o a.js -O3 -target cheerp
Carlo Piovesan
@carlopi
Possibly there is something strange in the folder being Cheerp\lib\clang\14.0.0, while it should be 15.0.0
Asuka
@Inori
Cheerp/xxx/14.0.0 is my download version from official website. there's no problem with it.
the 15.0.0 version is my self compiled version
it will crash with the same call stack from command line execute
the compiled version is compiled against 15.0.0 source files from within git cloned code
Carlo Piovesan
@carlopi
have you installed also cheerp-utils, cheerp-newlib & cheerp-libs from recent branches?
Asuka
@Inori
no, I didn't, are these the required components?
I think since I can build the compiler standalone, other components are not required, because they are not linked to the compiler
if it is, I'm going to try
Carlo Piovesan
@carlopi
Those components are required, I am not sure what's the more appropriate workflow on Windows, it will mostly be a copy of: https://docs.leaningtech.com/cheerp/Linux-build-instructions
Asuka
@Inori
so you mean the official release windows version is cross compiled on linux?
what I did on Windows has no difference with this: https://docs.leaningtech.com/cheerp/Windows-build-instructions
Carlo Piovesan
@carlopi
OK, you will still need recent pre-compiled libraries, as per:
Building the core compiler on Windows using Microsoft Visual Studio is fully supported, but building the base libraries (newlib, libc++, libc++abi) is not. You can grab a working copy from the latest release from any platform as they are platform independent. (same page you linked)
I am not sure what's the easiest way to fetch them, I will get back on this
Asuka
@Inori
is this by design to store the iterator in a map?
I think a iterator of std::deque will be invalid after many operations
Asuka
@Inori
this should be an UD, and behavior depends heavily on implementations
@carlopi
Carlo Piovesan
@carlopi
as specified just below: "When inserting at either end of the deque, references are not invalidated by insert and emplace." (https://en.cppreference.com/w/cpp/container/deque -> invalidation notes)
I believe deque when doing only push_backs guarantees iterators are never invalidated.
DeterministicMap is basically isolated from the rest of LLVM, so it should be easy to stress-test it in isolation
Asuka
@Inori

as specified just below: "When inserting at either end of the deque, references are not invalidated by insert and emplace." (https://en.cppreference.com/w/cpp/container/deque -> invalidation notes)
I believe deque when doing only push_backs guarantees iterators are never invalidated.

no, it says:

shrink_to_fit, clear, insert, emplace, push_front,
push_back, emplace_front, emplace_back

will Always invalidate iterators, In particular :push_back.see the Iterator invalidation chart

This message was deleted
When inserting at either end of the deque, references are not invalidated by insert and emplace
this is references invalidation rule, not iterators
Asuka
@Inori
and in practice, the problem solved when I force to use std::list as the underlying container
Asuka
@Inori
I think when memory is not enough, deque will allocate new memory block and chain it at end through internal structures while keeping the old memory block not moved, so memory reference/pointer to old block will always keep valid.
but maybe iterators are not implemented using reference/pointer on MSVC
Carlo Piovesan
@carlopi
thanks for pointing this out, I will review this, expecially with regard to MSVC