search for: codepreparation

...ASS_BEGIN * lib/CodeGen/CodegenCleanup.cpp:INITIALIZE_PASS_BEGIN(CodegenCleanup, "polly-cleanup", lib/CodeGen/CodeGeneration.cpp:INITIALIZE_PASS_BEGIN(CodeGeneration, "polly-codegen", lib/CodeGen/IslAst.cpp:INITIALIZE_PASS_BEGIN(IslAstInfo, "polly-ast", lib/Transform/CodePreparation.cpp:INITIALIZE_PASS_BEGIN(CodePreparation, "polly-prepare", lib/Transform/Canonicalization.cpp:INITIALIZE_PASS_BEGIN(PollyCanonicalize, "polly-canonicalize", lib/Transform/ScheduleOptimizer.cpp:INITIALIZE_PASS_BEGIN(IslScheduleOptimizer, "polly-opt-isl", lib/Transfo...

Hi Sebpop, Thanks for your explanation. I noticed that Polly would finally run the SROA pass to transform these load/store instructions into scalar operations. Is it possible to run such a pass before polly-dependence analysis? Star Tan At 2013-08-15 21:12:53,"Sebastian Pop" <sebpop at gmail.com> wrote: >Codeprepare and independent blocks are introducing these loads and

Codeprepare and independent blocks are introducing these loads and stores. These are prepasses that polly runs prior to building the dependence graph to transform scalar dependences into data dependences. Ether was working on eliminating the rewrite of scalar dependences. On Thu, Aug 15, 2013 at 5:32 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi all, > > I have investigated the

I do not think that running SROA before polly is a good idea: it would defeat the purpose of the code preparation passes that polly intentionally schedules for the data dependence analysis. If you remove the data references before polly runs, you would miss them in the dependence graph: that could lead to incorrect transforms. On Thu, Aug 15, 2013 at 7:28 PM, Star Tan <tanmx_star at

I just checkout release_38 branches of llvm, clang and polly and built it on and x86 Ubuntu with cmake: CMAKE_BUILD_TYPE="Debug" CMAKE_INSTALL_PREFIX="$HOME/toolchain/install/llvm-3.8" LLVM_TARGETS_TO_BUILD="X86" cmake -G "Unix Makefiles" \ -DBUILD_SHARED_LIBS="ON" \ -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \

...urrent version 56.0.0) and done with... /sw/var/lib/fink/path-prefix-clang/c++ -fPIC -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -g -bundle -Wl,-headerpad_max_install_names -Wl,-flat_namespace -Wl,-undefined -Wl,suppress -L/sw/lib -o ../../../lib/LLVMPolly.so CMakeFiles/LLVMPolly.dir/CodePreparation.cpp.o CMakeFiles/LLVMPolly.dir/DeadCodeElimination.cpp.o CMakeFiles/LLVMPolly.dir/IndependentBlocks.cpp.o CMakeFiles/LLVMPolly.dir/IndVarSimplify.cpp.o CMakeFiles/LLVMPolly.dir/MayAliasSet.cpp.o CMakeFiles/LLVMPolly.dir/Pocc.cpp.o CMakeFiles/LLVMPolly.dir/RegionSimplify.cpp.o CMakeFiles/LLVMPolly.d...

Hi all, I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces

Jack, I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 means the initializer called something which