similar to: [LLVMdev] Loop Metadata?

On Feb 10, 2012, at 10:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Is there currently a good way of attaching metadata to loops? > > The use case that I have in mind is implementing a feature whereby the > user can put > #pragma unroll(N) > above a loop and that serves has an instruction to the optimizer to > unroll the loop N times. > > I understand that

On Fri, Feb 10, 2012 at 1:14 PM, Devang Patel <dpatel at apple.com> wrote: > > On Feb 10, 2012, at 10:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> Is there currently a good way of attaching metadata to loops? >> >> The use case that I have in mind is implementing a feature whereby the >> user can put >> #pragma unroll(N) >> above a

On Feb 10, 2012, at 1:42 PM, Sebastian Pop <spop at codeaurora.org> wrote: > On Fri, Feb 10, 2012 at 1:14 PM, Devang Patel <dpatel at apple.com> wrote: >> >> On Feb 10, 2012, at 10:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> Is there currently a good way of attaching metadata to loops? >>> >>> The use case that I have

----- Original Message ----- > From: "Bjorn De Sutter" <bjorn.desutter at elis.ugent.be> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 27, 2012 6:49:39 AM > Subject: Re: [LLVMdev] loop pragmas > > I am thinking about another use of annotations that fits in a longer > term vision, which centers around feeding compilers with information > from

On 11/21/2012 11:32 AM, Tobias Grosser wrote: > On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >> >> I'm thinking of this in terms of parallelization directives. The >> optimizations that rely on such annotations would need to be done as >> early as possible, before any optimization that could invalidate them. >> If the annotation can become false, you are

Hal, I'm opening a new discussion on vectorization metadata, since it has little to do with fp-math. ;) What kind of metadata would you annotate in the instructions? If I remember from your talk, you're not doing any loop or whole-function analysis, possibly leaving it for Polly to help you along the way. I remember discussing it with Tobias that Polly could have three main steps: 1.

Hi Ether, On 18 April 2012 19:11, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Instead of exporting the polyhedral model of the program with > metadata, another possible solution is designing a generic "Loop > Parallelism" analysis interface just like the AliasAnalysis group. > For a particular loop, the interface simply answer how many loop > iterations can run

Is it OK to remove metadata in an optimization pass? The context is patch http://reviews.llvm.org/D4571 which removes loop unrolling hint metadata after using it to avoid unrolling more than the hint suggests. This is a potential problem because loop unrolling can be run more than once. Example: a loop annotated with "#pragma clang loop unroll_count(2)" which adds hint metadata to the

> Other types of annotations that are > "harmless" are probably good to have, for example "unroll-by" (assuming > that this is a suggestion to the compiler, not an order). | To my knowledge, we are avoiding to allow the user to 'tune' the | compiler. Manual tuning may be good for a certain piece of hardware, but | will have negative effects on other platforms.

Nadav Rotem wrote: > > On Feb 7, 2013, at 10:55 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > > > Hi Nadav, > > > > On 02/07/2013 07:46 PM, Nadav Rotem wrote: > >> Pekka suggested that we add two kind of metadata: llvm.loop.parallel > >> (attached to each loop latch) and llvm.mem.parallel (attached to each memory > >>

On Feb 7, 2013, at 10:55 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi Nadav, > > On 02/07/2013 07:46 PM, Nadav Rotem wrote: >> Pekka suggested that we add two kind of metadata: llvm.loop.parallel >> (attached to each loop latch) and llvm.mem.parallel (attached to each memory >> instruction!). I think that the motivation for the first

On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is beneficial or not - however, this is future music. > > Isn't that part

On 11/21/2012 12:48 PM, Tobias Grosser wrote: > On 11/21/2012 06:56 PM, Krzysztof Parzyszek wrote: >> >> Yes, that is not hard to accomplish. > > Actually, I believe this is _not_ easy. Though, it makes only sense to > discuss this with a specific annotation in mind. Agreed. If there is a dedicated consumer of certain annotations, then after it's done, it should

I am thinking about another use of annotations that fits in a longer term vision, which centers around feeding compilers with information from higher-level tools such as precompilers. Deciding how to map a portable piece of software to a heterogeneous multicore processor and get the best performance for a range of widely varying architectures, requires much higher level code analysis than what is

On May 23, 2013, at 8:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> >> >> Hi, >> >> Just from personal interest, is there a canonical way in IR+metadata >> to express "This small constant trip-count loop is desired to be >> converted into a sequence of vector operations directly"? Ie,

Hi llvm-dev! We are doing some fuzzy testing using C program generators, and one question that came up when generating a program with both floating point arithmetic and loop pragmas was; Is the loop vectorizer really allowed to vectorize a loop when it can't prove that it is safe to reorder fp math, even if there is a loop pragma that hints about a preferred width. When reading here

Hi, I've been looking at several loop pragma discussion threads, and every now and then, people note that it is difficult to ensure that metadata (that would represent the information from the pragma) is not destroyed during optimizations. I understand that in theory CFG transformations might destroy loops, but in practice, I notice that even after heavy optimization with opt and after

On Wed, 18 Apr 2012 20:17:35 +0100 Renato Golin <rengolin at systemcall.org> wrote: > Hi Ether, > > On 18 April 2012 19:11, Hongbin Zheng <etherzhhb at gmail.com> wrote: > > Instead of exporting the polyhedral model of the program with > > metadata, another possible solution is designing a generic "Loop > > Parallelism" analysis interface just

On 16/01/2014, 23:47 , Andrew Trick wrote: > > On Jan 15, 2014, at 4:13 PM, Diego Novillo <dnovillo at google.com > <mailto:dnovillo at google.com>> wrote: > >> Chandler also pointed me at the vectorizer, which has its own >> unroller. However, the vectorizer only unrolls enough to serve the >> target, it's not as general as the runtime-triggered

On 11/21/2012 6:53 AM, Tobias Grosser wrote: > > o Blocks future optimizations > > At the moment LLVM performs little loop optimizations. Hence, the > original structure is not changed too much. I'm thinking of this in terms of parallelization directives. The optimizations that rely on such annotations would need to be done as early as possible, before any optimization that