similar to: [LLVMdev] optimization passes through c++

If we were to implement the #unroll pragma, we would want to add metadata to loop headers. But, it's not a big deal since we can simply add this metadata to block terminators. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, May 08, 2012 00:58 To: Ralf Karrenberg Cc: llvmdev at cs.uiuc.edu List

Hi Duncan, On 5/6/12 6:12 PM, Duncan Sands wrote: > Hi Ralf, > >> Is there a clean way to attach metadata nodes to Arguments and/or >> BasicBlocks? > > not at the moment. Feel free to work on adding this functionality! I am looking into that now. I decided to temporarily go for the following syntax for BasicBlock metadata (subject to discussion): entry:

On 5/9/12 2:01 AM, Dan Gohman wrote: > > On May 7, 2012, at 11:11 PM, Ralf Karrenberg<Chareos at gmx.de> wrote: > >> Hi Dan, >> >> I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may never diverge in different instances ("threads" if you think in terms of

On May 7, 2012, at 7:21 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf, >> >>> Is there a clean way to attach metadata nodes to Arguments and/or >>> BasicBlocks? >> >> not at the moment. Feel free to work on adding this functionality! > > I am looking into that

On 5/9/12 5:08 PM, Dan Gohman wrote: > > On May 8, 2012, at 11:37 PM, Ralf Karrenberg wrote: > >> On 5/9/12 2:01 AM, Dan Gohman wrote: >>> >>> On May 7, 2012, at 11:11 PM, Ralf Karrenberg<Chareos at gmx.de> wrote: >>> >>>> Hi Dan, >>>> >>>> I am using it to store results of a vectorization analysis. A BasicBlock

Indeed, Nadav. I also want to store information about loops as block-metadata of the loop header, but as you say this is easily doable by using block terminators. However, for the divergence analysis, we cannot use the terminators, because the properties of a block are determined by multiple criterions. If you do not want to introduce ugly dummy-calls to store that data (and write even more

Hi Dan, I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may never diverge in different instances ("threads" if you think in terms of CUDA) of the same function by marking the corresponding blocks. This information is later used when linearizing the function (control flow to data flow

On May 8, 2012, at 11:37 PM, Ralf Karrenberg wrote: > On 5/9/12 2:01 AM, Dan Gohman wrote: >> >> On May 7, 2012, at 11:11 PM, Ralf Karrenberg<Chareos at gmx.de> wrote: >> >>> Hi Dan, >>> >>> I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

Hi everybody, On 10/17/12 12:32 AM, Hal Finkel wrote: >>> Do you have a plan for xforms to increase the amount of >>> vectorization? >> >> Yes. We will need to implement a predication phase and to design the >> interaction with other loop transformations. Also, this will have to >> work well with the cost model. We also need to think of a good way to

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

Hello everyone, I'd like to know if there is an optimization in llvm doing something like an if-conversion on the IR. I only found IfConversion.cpp which appears to only provide the desired functionality on machine code during code-generation. I want to transform branches into serial code with select-instructions as a pre-processing step for further transformations. If there is no such

----- Original Message ----- > Hi Preston! > > > > > I'd start by making a plan (a design!) with goals and stuff. > > Publish it so we can see what you mean by "vectorization". > > I will send a separate email later, but here is a quick overview. I > see the vectorizer having four main components: > > 1. Preparation passes: If-conversion,

Its a good point. We will need to document the semantics of the vectorization pragma well. On Nov 14, 2013, at 10:58 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Nadav, > > On 14/11/13 17:38, Nadav Rotem wrote: >> Sure. Vectorization of stores is done by loading the current value from memory, blending the new value and saving it back to memory. > > Just a

On May 7, 2012, at 11:11 PM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Dan, > > I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may never diverge in different instances ("threads" if you think in terms of CUDA) of the same function by marking the corresponding blocks.

Hi, The last time the AVX backend was mentioned on this list seems to be from November 2010, so I would like to ask about the current status. Is anybody (e.g. at Cray?) still actively working on it? I have tried both LLVM 2.9 final and the latest trunk, and it seems like some trivial stuff is already working and produces nice code for code using <8 x float>. Unfortunately, the backend

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Ralf Karrenberg" <Chareos at gmx.de> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, January 31, 2013 11:15:43 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL C work group autovectorization > > Hi

Hi, I am expieriencing strange behaviour of llvm's optimization passes and I don't understand what I am doing wrong. Basically all I've done is extracting code for optimization of a llvm-function in a llvm-module and put it into a separate function for better readability. The original code looks like follows (and works as expected): ----------------------------- std::string

Hi, On 13.06.2013 20:15, Xinliang David Li wrote: > GCC's optimize attribute should work fine (at least with trunk): > > __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) > { > ... > } > > will turn on -O3 for 'foo', but disable PRE pass for it. Indeed, the optimize attribute should do the job if you require optimization