Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Asuka
    @Inori
    image.png
    @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.

    See this wikipedia page: https://en.wikipedia.org/wiki/Structured_program_theorem
    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:
    http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.1485&rep=rep1&type=pdf.
    Asuka
    @Inori
    hi, I'm trying to compile and run cheerp-compiler on windows
    image.png
    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.
    image.png
    image.png
    image.png
    some call stack information
    Carlo Piovesan
    @carlopi
    can you share the testcase triggering this problem?
    Asuka
    @Inori
    hello.cpp
    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
    image.png
    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
    image.png
    is this by design to store the iterator in a map?
    I think a iterator of std::deque will be invalid after many operations
    image.png
    https://en.cppreference.com/w/cpp/container/deque
    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