search for: hoistable

...was okay to do so. When compilation broke, http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130812/184331.htm l further suggested that the intention is that you can... but I do not see how a hoist can ever pass verification/compile correctly. Am I doing something incorrectly here? Or are hoistable spills just that rare on GPU code that it's never come up? As a side note, compiler option "-disable-spill-hoist" (DisableHoisting) is referenced in exactly zero places, so if anyone in a similar situation finds this post, maybe don't bother testing with that flag just yet. :)

...se it is very much like @llvm.assume. And like @llvm.assume, we'll need to add logic to various passes to ignore it as appropriate so that it does not block optimizations unnecessarily. I was hoping this avoid this part of the design space, but I don't see any way around it -- only some non-hoistable instruction can model a control dependence. With this in place, it will be possible to build a loop-aware AA interface capable of answering questions like: Does location A in some loop iteration alias with location B in any iteration (which is really what the vectorizer wants to know). This interf...

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

...te that if the address > space conversion is legal then both result and operand refer to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast? Does this > axiom make addrspacecast non-hoistable? From a quick glance at > the code, ValueTracking seems to assume that addrspacecasts can be > speculatively executed. > > 2. even if two pointers from two different address spaces point to > the same "location", can one of them not be dereferenceable while >...

...se. You can’t reason about it the way you would ordinarily reason about uses. For example: if (%c) %v = load %p !notrap !{ %c } If !{ %c } were an ordinary use then you could transform this to: if (%c) %v = load %p !notrap !{ 1 } But then the world breaks: it would seem that the load is hoistable to anywhere. So, we would have to come up with some special new rules for what you can do to a !{ %c } use; likely this would involve conservatively erasing the meta-data if you did *anything* to %c. NEW PROPOSAL The solution is to introduce meta-data that is explicit about how the safe-to-execu...

...gt; > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130812/184331.htm > > l further suggested that the intention is that you can... but I do not > see > > how a hoist can ever pass verification/compile correctly. Am I doing > > something incorrectly here? Or are hoistable spills just that rare on GPU > > code that it's never come up? > Hi Alex, I havn't noticed before that TII.storeRegToStackSlot is allowed to create new virtual registers. I am surprised to know it is allowed to do that. I am mostly working on x86 and TII.storeRegToStackSlot for x...

----- Original Message ----- > > > > On Nov 1, 2013, at 4:48 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > Hi Nadav, > > On 10/31/2013 08:53 PM, Nadav Rotem wrote: > > > data-parallel languages which have a completely different > semantics. In > OpenCL/Cuda you would want to vectorize

On Nov 1, 2013, at 4:48 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> Hi Nadav, >> >> On 10/31/2013 08:53 PM, Nadav Rotem wrote: >>> data-parallel languages which have a completely different >>> semantics. In >>> OpenCL/Cuda you would want to vectorize the outermost loop, and the >>> language

> On 2 Aug 2018, at 14:50, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > Hi Daniel, > > 2018-07-31 8:40 GMT-07:00 Daniel Sanders <daniel_l_sanders at apple.com>: >> >> >> On 30 Jul 2018, at 16:04, Quentin Colombet via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Hi Amara, >> >> Thanks for