similar to: [LLVMdev] Proposal for safe-to-execute meta-data for heap accesses

On Nov 8, 2013, at 11:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> >> >> >> >> On Nov 8, 2013, at 1:13 AM, Chandler Carruth < chandlerc at google.com > >> wrote: >> >> >> >> >> >> >> >> >> On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo <

> On Nov 8, 2013, at 1:13 AM, Chandler Carruth <chandlerc at google.com> wrote: > > >> On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo <fpizlo at apple.com> wrote: >> NEW PROPOSAL >> >> The solution is to introduce meta-data that is explicit about how the safe-to-execute condition ought to be evaluated. Instead of an SSA use, we can have meta-data that

----- Original Message ----- > > > > > > On Nov 8, 2013, at 1:13 AM, Chandler Carruth < chandlerc at google.com > > wrote: > > > > > > > > > On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo < fpizlo at apple.com > > wrote: > > > > NEW PROPOSAL > > The solution is to introduce meta-data that is explicit

On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo <fpizlo at apple.com> wrote: > NEW PROPOSAL > > The solution is to introduce meta-data that is explicit about how the > safe-to-execute condition ought to be evaluated. Instead of an SSA use, we > can have meta-data that says: > > %v = load %p !notrap !{ @f, <args> } > > where @f is a function in the

On Nov 8, 2013, at 9:36 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Fri, Nov 8, 2013 at 8:44 AM, Filip Pizlo <fpizlo at apple.com> wrote: >> Is the expectation that to utilize this metadata an optimization pass would have to inspect the body of @f and reason about its behavior given <args>? > > Yes. > >> >> If so, then I

On Fri, Nov 8, 2013 at 8:44 AM, Filip Pizlo <fpizlo at apple.com> wrote: > Is the expectation that to utilize this metadata an optimization pass > would have to inspect the body of @f and reason about its behavior given > <args>? > > > Yes. > > > If so, then I think this is pretty bad. If we ever want to parallelize > function passes, then they can't

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

Thanks for the background on the concurrent memory model. So, is it sufficient that the loop entry is guarded by condition (cbz at top) for preventing the race? The loop entry will be guarded by condition if loop has been rotated by loop rotate pass. Since LICM runs after loop rotate, we can use ScalarEvolution::isLoopEntryGuardedByCond to check if we can speculatively execute load without

----- 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 April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only makes sense for C and its very direct relatives.  The amount of control flow necessary to represent a safe division for any other language is ghastly.  (a/b) becomes something like (b != 0 ? ((a != INT_MIN ||

I think gcc is right. It inserted a branch for n == 0 (the cbz at the top), so that's not a problem. In all other regards, this is safe: if you examine the sequence of loads and stores, it eliminated all but the first load and all but the last store. How's that unsafe? If I had to guess, the bug here is that LLVM doesn't want to hoist the load over the condition (which it is right

----- 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 guarantees that it is safe to so. > > Yeah. This is the separate (old) discussion and not strictly

On 7 June 2014 00:14, Filip Pizlo <fpizlo at apple.com> wrote: > The only setback is to ensure that we synchronize the renaming with WebKit. > > The WebKit->LLVM interface currently avoids revision-lock; you can take any > recent revision of either and build a working browser engine. This is mostly > true even when we change the stack map format because of versioning in the

On Sat, Jun 7, 2014 at 6:30 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On June 7, 2014 at 1:29:04 PM, Alp Toker (alp at nuanti.com) wrote: > > > On 07/06/2014 18:35, Filip Pizlo wrote: >> That would work. :-) >> >> What about exposing C API a function to query for the presence of an >> intrinsic? > > It seems with hindsight that the

On April 25, 2014 at 9:52:35 AM, Eric Christopher (echristo at gmail.com) wrote: Hi Michael, > I’d like to propose to extend LLVM IR intrinsics set, adding new ones for > safe-division. There are intrinsics for detecting overflow errors, like > sadd.with.overflow, and the intrinsics I’m proposing will augment this set. > > The new intrinsics will return a structure with two

On 07/06/2014 18:35, Filip Pizlo wrote: > That would work. :-) > > What about exposing C API a function to query for the presence of an intrinsic? It seems with hindsight that the "experimental" prefix has turned out to be a waste of time. At least without the prefix there was a good chance this churn could be avoided as long as the original review was sound, whereas the

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 guarantees that it is safe to so. Yeah. This is the separate (old) discussion and not strictly related to the problem at hand. Better if-conversion benefits more than OpenCL C

Hi Pekka, The motivation for the ’notrap’ bit is clear. Domain specific languages can set this bit to enable more aggressive optimizations. I don’t think that the Loop Vectorizer is a good example because it is not designed to vectorize data-parallel languages which have a completely different semantics. In OpenCL/Cuda you would want to vectorize the outermost loop, and the language

> On Aug 18, 2014, at 4:25 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > >> On Aug 18, 2014, at 3:21 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> >>>> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> >>>> Some passes take options directly in the

Once LLVM is built and used as a dylib, we'd just mark the zlib symbols as hidden. :-) I tend to think that bundling is ugly because it makes it harder for a distributor or integrator to pick the exact versions of all of the components in the system. I don't know if this was mentioned already, but maybe we can have a compromise where a configure option can be used to select between the