similar to: [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA]

> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? I think it is not possible in general, but I believe it is possible in case of affine expressions used as GEP indices. I assume, GEP indices (except indexing into struct) are interpreted as signed integers. It isn't explicitly stated in the LangRef, but

In the general case, I think you have to be conservative about this because programmers may deliberately want this kind of "wraparound" behavior, e.g., with periodic boundary conditions. But 99.9% of programs probably don't need that so it would be bad to penalize them for this corner case. In such a situation, I think you just have to support both choices, but choose the

On Aug 22, 2008, at 9:30 AM, Vikram S. Adve wrote: > In the general case, I think you have to be conservative about this > because programmers may deliberately want this kind of "wraparound" > behavior, e.g., with periodic boundary conditions. But 99.9% of > programs probably don't need that so it would be bad to penalize them > for this corner case. In such a

On Aug 22, 2008, at 9:34 AMPDT, Chris Lattner wrote: > > On Aug 22, 2008, at 9:30 AM, Vikram S. Adve wrote: > >> In the general case, I think you have to be conservative about this >> because programmers may deliberately want this kind of "wraparound" >> behavior, e.g., with periodic boundary conditions. But 99.9% of >> programs probably don't need

Great, thanks! How much work do you think it will take to bring it up to date with the LLVM IR, except *ignoring* first-class structs and arrays for now? I believe llvm-gcc does not generate those in most cases and we can do a lot without supporting those. What else is missing relative to the current LLVM IR? Thanks, --Vikram Associate Professor, Computer Science University of

On Aug 22, 2008, at 9:53 AM, Dale Johannesen wrote: >> >> C has a way to express this: signed integers are defined to never >> overflow, > > More precisely, signed integer overflow is undefined behavior, which > gives the compiler great latitude. > Assuming this will never happen and doing optimizations on that basis > is valid, but so are other things. > An

> Thanks! This is all very interesting, and tells me that LLVM has a > way to go to fully support all of these capabilities (if that is the > right thing to do, which isn't clear). OTOH, it looks like a lot of > real-world software that is using LLVM already doesn't seem to be > affected by the lack of them. LLVM's current choice is safe for all applications. The

On Aug 22, 2008, at 11:53 AM, Dale Johannesen wrote: > > On Aug 22, 2008, at 9:34 AMPDT, Chris Lattner wrote: > >> >> On Aug 22, 2008, at 9:30 AM, Vikram S. Adve wrote: >> >>> In the general case, I think you have to be conservative about this >>> because programmers may deliberately want this kind of "wraparound" >>> behavior, e.g.,

I have written test.ll as below and ran 'opt' on it as " opt -std-compile-opts test.ll -S -o -" . But the output shows that there is code motion around the barrier intrinsics. test.ll ------- ; ModuleID = 'test.bc' define void @test(i16* %I_0, i16* %I_1, i16* %I_2, i16* %I_3, i16* %O_0) { entry: %T_0 = load volatile i16* %I_0 %T_1 = load volatile i16* %I_1 %T_2 =

is there any guarantee that the nvptx intrinsic "llvm.nvvm.barrier0" will not be moved around by opt ? In other words, can I expect all the instructions above "llvm.nvvm.barrier0" to remain above it and those below it to remain below, after all the opt passes are run ? If that is not the case, is there a way to define such an intrinsic ? Thanks. -------------- next part

On Sun, Aug 24, 2008 at 2:46 PM, Wojciech Matyjewicz <wmatyjewicz at fastmail.fm> wrote: >> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? > > I think it is not possible in general, but I believe it is possible in > case of affine expressions used as GEP indices. > > I assume, GEP indices

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

Hi, On Fri, 2008-08-29 at 09:24 -0700, Devang Patel wrote: [...] > - Put various tests, DeltaTest, in lib/Analysis folder. The > transformation pass does not need to see these details. I believe some low-level tests should actually not be implemented as a separate Analysis but placed into Support. For instance, DeltaTest would use GCD or other tests on a different set of indexes once

Wojtek, Please see David's message below. Have you or can you check in your code, perhaps as a project for now? That will allow us to start looking at it and perhaps collaborating on it. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Aug 20, 2008, at 3:05 PM, David Greene wrote: > On Wednesday 20 August 2008

On Wednesday 20 August 2008 14:07, Vikram S. Adve wrote: > At Illinois, we are working on a parallelizing compiler but we're at > an extremely early stage. We too will need a dependence analysis > interface that can support fairly aggressive analysis, including > strong tests, direction vectors, perhaps distance vectors, and > dependence breaking conditions. We were going to

On Aug 29, 2008, at 10:15 AM, Matthieu Delahaye wrote: > Hi, > > On Fri, 2008-08-29 at 09:24 -0700, Devang Patel wrote: > [...] >> - Put various tests, DeltaTest, in lib/Analysis folder. The >> transformation pass does not need to see these details. > > > I believe some low-level tests should actually not be implemented as a > separate Analysis but placed into

On Aug 21, 2008, at 1:37 AM, Wojciech Matyjewicz wrote: > I am investigating what changes are necessary to add support for > first-class structs and arrays and will prepare a version to check > in as > a LLVM project if there still is interest. We want to model this as an analysis and make following changes. - Rename LoopMemDepAnalysis as DataDependenceAnalysis. Various

Thanks! This is all very interesting, and tells me that LLVM has a way to go to fully support all of these capabilities (if that is the right thing to do, which isn't clear). OTOH, it looks like a lot of real-world software that is using LLVM already doesn't seem to be affected by the lack of them. Does anyone know of any C/C++ programs that require integer overflow on signed

On Fri, Aug 22, 2008 at 5:49 PM, John Regehr <regehr at cs.utah.edu> wrote: >> Thanks! This is all very interesting, and tells me that LLVM has a >> way to go to fully support all of these capabilities (if that is the >> right thing to do, which isn't clear). OTOH, it looks like a lot of >> real-world software that is using LLVM already doesn't seem to be

Wojtek Matyjewicz has written a simple DependenceAnalysis interface and sent email about it to llvmdev in June -- the message is attached. He said he wrote several tests behind that interface -- ZIV, strong SIV, Banerjee, and some form of the Delta test -- and two students in my Spring class added the Omega test. I have not reviewed his interface yet because I've been traveling