search for: llvm_metadata_ti

On 01/11, Daniel Berlin via llvm-dev wrote: > > > > def int_experimental_directive : Intrinsic<[], [llvm_metadata_ty], > > [IntrArgMemOnly], > > "llvm.experimental.directive">; > > > > def int_experimental_dir_qual : Intrinsic<[], [llvm_metadata_ty], > > [IntrArgMemOnly], > >

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

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:

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

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

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

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

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

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

This is for BPF output. BPF program output bytes to perf through a tracepoint. For decoding such data, we need a way to describe the format of the buffer. This patch is a try which gives each variable a unique number by introducing a new intrinsic 'llvm.typeid.for'. At the bottom is an example of using that intrinsic and the result of $ clang -target bpf -O2 -c -S ./test_typeid.c

On 2015/8/12 12:57, Alexei Starovoitov wrote: > On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote: >> Think about a program like this: >> >> struct strA { int a; } >> struct strB { int b; } >> int func() { >> struct strA a; >> struct strB b; >> >> a.a = 1; >> b.b = 2; >>