search for: diptorup

Hi, We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the upgrade our module works when built with an LLVM Debug build, but with an LLVM Release build we are encountering the following error. This happens after our passes have successfully run. I believe this has to do with the way our passes are registered. Would greatly appreciate some pointers, as to where to look. Program

Hi, We have a research LLVM-based domain-specific code generator that we want to upgrade form LLVM 4.0 to 5.0. The code generator is written as an out-of-tree loadable module for opt. Till Clang 4.0 we were compiling the front-end code (annotated C++) using -O0. The generated bitcode was further processed using opt with our module loaded. In Clang 5.0 we see that using -O0 adds the optnone

...t;mailto:llvm-dev at lists.llvm.org>> wrote: To prevent optnone from being added you can replace -O0 with "-O1 -Xclang -disable-llvm-passes". The -O1 will prevent the optnone, and the rest will stop clang from performing any optimizations. ~Craig On Sun, Sep 17, 2017 at 10:12 PM, Diptorup Deb via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, We have a research LLVM-based domain-specific code generator that we want to upgrade form LLVM 4.0 to 5.0. The code generator is written as an out-of-tree loadable module for opt. Till Clang 4....

On 9/18/2017 8:20 PM, Diptorup Deb via llvm-dev wrote: > Hi, > > We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the > upgrade our module works when built with an LLVM Debug build, but > with an LLVM Release build we are encountering the following error. > > This happens after our passes ha...

Hello, I am working on a C++ expression templates based DSL where we are using LLVM for the code generation. I needed some help in understanding the behaviour of the LICM pass. In the following example code the "A" class is a custom container that defines various arithmetic operators using expression templates. We are defining three arrays of the "A" container and aggregating

On 09/28, Alexandre Isoard wrote: > Polly is oriented towards providing a full blown polyhedral compiler > pipeline, this is great in the sense that it allows to do all the high > level transformations we can dream of, but this is also difficult to > compose with current LLVM passes, we lose debug information, and it is > relatively hard to control what happen. As such, it might be