similar to: [LLVMdev] LLVM CreateStructGEP type assert error

cB->getType()->getPointerElementType()->dump(); gives: %struct.RB = type opaque2189 x_idx = builder.CreateStructGEP(cB, 0); cB->dump() gives: %struct.RB addrspace(1)* %cB $1 = void //To undo confusion, the last cB is the function arg name. For this example I unfortunately chose the same name for my argument Value* as the argument name. //Also one correction. I am running

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int x; unsigned int y; int z[BUFFER_LEN]; unsigned int xx[BUFFER_LEN];

More precisely, for a simd loop, if the safelen(VL) clause is specified, there should have no loop-carried lexical backward data dependency within the specified safe vector length VL. We will make this clear in the OpenMP 4.1 spec. Xinmin Tian (Intel) -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent:

Yes, I think the 2 outcomes are: - the current spec is unclear and will be clarified - in order to support safelen() and even the simd construct itself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced. Jon -----Original Message----- From: Tian, Xinmin [mailto:xinmin.tian at intel.com] Sent: Monday, September 29, 2014 10:43 AM To:

It's a problem in the OpenMP specification. The authors (including some from Intel) intended that the OpenMP simd construct assert no lexically backward dependences exist, but as you say, it's not obvious from the spec. One of our OpenMP community members is going to bring up the ambiguity with the OpenMP committee. - Arch -----Original Message----- From: Humphreys, Jonathan

> Sorry for coming to the discussion so late. I have a couple of questions/comments: Actually, you're note is timely, because I'm planning to send out a patch (as soon as I update LangRef and rerun tests) that supports safelen but *not* lexical dependences. I don't need the safelen for Julia, but having done the work and seeing that OpenMP needs it, feel that I should finish the

On 08/20, Arnold Schwaighofer wrote: > > > On Aug 20, 2014, at 8:08 AM, Robison, Arch <arch.robison at intel.com> wrote: > > > >> I recommend that you send patches for an implementation > >> (including the Loop::GetAnnotatedVectorSafelen function > >> and associated updates to the vectorizer) for review. > > > > I expect to send the

> I recommend that you send patches for an implementation > (including the Loop::GetAnnotatedVectorSafelen function > and associated updates to the vectorizer) for review. I expect to send the patches for review later this week. > Make sure to remember LangRef updates! Thanks for the reminder. > Also, looking at the original proposal again, I see no reason > to restrict

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.com> > To: "Johannes Doerfert" <doerfert at cs.uni-saarland.de> > Cc: llvmdev at cs.uiuc.edu, "Arch Robison" <arch.robison at intel.com> > Sent: Wednesday, August 20, 2014 11:29:16 AM > Subject: Re: [LLVMdev] Proposal for

Julia and OpenMP 4.0 have features where the user can bless a loop as having no memory dependences that prevent vectorization, thus enabling vectorization of loops not amenable to compile-time or run-time dependence analysis. LLVM currently has no metadata to express such, as explained further below. I'd like to propose new metadata that enables front-ends to tell the vectorizer that

Here's an attempt to nail down the annotation semantics with support for respecting forward lexical dependences. Each load, store, call, or invoke instruction can be labeled with !llvm.mem.vector_loop_access, which has two operands: * The first operand is an integer denoting lexical position. The positions need not be consecutive, and may contain duplicates. * The second operand is the

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev" > <llvmdev at cs.uiuc.edu> > Sent: Wednesday, August 20, 2014 2:21:08

On 28 September 2014 22:09, Hal Finkel <hfinkel at anl.gov> wrote: > Thanks Xinmin! > > So we'll need a method to ensure the correct (partial) ordering. I thought that the idea was to avoid computing loop dependencies when safelen is specified, at least at that level. We might do it to a greater length, but we should assume it to be safe for distances < VL. We still need

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev" > <llvmdev at cs.uiuc.edu> > Sent: Wednesday, August 20, 2014 2:16:56

----- Original Message ----- > From: "Roel Jordans" <r.jordans at tue.nl> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, August 13, 2014 5:57:15 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > > WHY CURRENT METADATA DOES NOT SUFFICE > > ------------------------------------- > > > > There

Today command line arguments in LLVM are global variables. An example argument from Scalarizer.cpp is: static cl::opt<bool> ScalarizeLoadStore ("scalarize-load-store", cl::Hidden, cl::init(false), cl::desc("Allow the scalarizer pass to scalarize loads and store")); This poses a problem for clients of LLVM that aren’t traditional compilers (i.e. WebKit, and Mesa).

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the

> On Aug 19, 2014, at 12:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> I strongly feel this is the wrong decision. If you have a single process using two LLVM clients (say WebKit and Mesa), and they both are using an opt pass with different settings. If the storage is global this will not work. > > That is only an issue if they can set the option at

While playing with SLPVectorizer, I notice that it will happily vectorize cases involving extractelement/insertelement, but won't vectorize isomorphic cases involving extractvalue/insertvalue (such as the attached example). Is that something that could be straightforward to add to SLPVectorizer, or are there some hard issue? In particular, the transformation would seem to require casts of