similar to: [LLVMdev] loop pragmas

----- 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/20/2012 08:56 PM, Bjorn De Sutter wrote: > 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

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 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

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

Hi all, I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we support or, and, and conditional predicates (see Scott Mahlke's papers on this

Hi Sergei, thanks for considering my question. We if-convert some code, such that the basic block looks as follows after if-conversion: ld char from A into R1 p1 = R1>255? (generate the predicate) p1 | R1 = 255 (conditional execution) st char R1 to A ld char from A+1 into R2 p2 = R2>255? (generate the predicate) p2 | R2 = 255 (conditional execution) store char R2 to A+1 The problem is

Hi, that solved my problem on trunk as well, thanks. Strange that you have to include this though. Bjorn On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > Hi, > > I accidentally stumbled upon your post. > I observed similar behaviour whenever I did not include > > #include "llvm/Support/Debug.h" > #include

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

David, one quick question, is there a way to preserve and associate a set of “properties, value info/attr ” to the given region using Token? Thanks, Xinmin From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Majnemer via llvm-dev Sent: Wednesday, January 11, 2017 2:18 PM To: Hal Finkel <hfinkel at anl.gov> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject:

Would you send us the LLVM IR for below example using token and OpBundle. So, we can understand better. Thanks. #pragma omp target teams distribute parallel for simd shared(xp, yp) linear(i) firstprivate(m, n) map(m, n) for (i=0; i<2*N; i++) { xp[i*m + j] = -1; yp[i*n +j] = -2; } #pragma prefetch x:1:20 y:0:10 for (i=0; i<2*N; i++) { xp[i*m + j] = -1; yp[i*n +j] = -2; } From: Hongbin

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

Mehdi, thanks for good questions. >>>>>Something isn’t clear to me about how do you preserve the validity of the region annotations since regular passes don’t know about the attached semantic? There are some small changes we have to make in some optimizations to make sure the optimizations does not validation attached annotation semantics. 1) provide hand-shaking / query utils for

Interesting, this is similar to what we have. One more question, these stuff in the yellow, are they represented as LLVM VALUEs? In other words, does the LLVM optimizer update them? ,E.g. %m is re-named %m.1 in the loop, is the “m” in the token @..... is updated as well? In the RFC, the “m” is argument of intrinsic call, all use-def info are used by optimizer, and optimizer updates them

On 11/27/2012 8:03 AM, Hal Finkel wrote: > > This still leaves the question of exactly how to attach metadata to loops, etc. In one implementation, the loops had a fixed structure: guard branch, preheader, header and loop body, optional epilog. The structure was clearly identified by various means (flags, bits, etc.). No optimization in the optimizer (roughly a counterpart of the

+1, tokens are the current True Way to create single-entry multi-exit regions. Your example for an annotated loop would look like: %region = call token @llvm.openmp.regionstart(metadata ...) ; whatever parameters you need here loop call void @llvm.openmp.regionend(token %region) If you use tokens, I would recommend proposal (c), where you introduce new intrinsics for every new kind of region,

And “map” and “firstprivate” … are represented as MDString, right? Thanks. From: Hongbin Zheng [mailto:etherzhhb at gmail.com] Sent: Wednesday, January 11, 2017 3:58 PM To: Tian, Xinmin <xinmin.tian at intel.com> Cc: David Majnemer <david.majnemer at gmail.com>; Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] IR-level Region

A Proposal for adding an experimental IR-level region-annotation infrastructure ============================================================================= Hal Finkel (ANL) and Xinmin Tian (Intel) This is a proposal for adding an experimental infrastructure to support annotating regions in LLVM IR, making use of intrinsics and metadata, and a generic analysis to allow transformations to

> (d) Add a small number of LLVM intrinsics for region or loop annotations, > represent the directive/clause names using metadata and the remaining > information using arguments. > > Here we're proposing (d), I think this would serve the goal of communicating source-level directives and annotations down to LLVM passes and back-ends, while deferring inlining and