similar to: [LLVMdev] Flow-Sensitive AA

Hello All, I have met a case with restrict keyword and I have a question about it. Let's look at a simple example. char buf[4]; void test(char *restrict a, char *restrict b, int count) {   for (unsigned i = 0; i < count; i++) {     *a = *b;     a++;     b++;     buf[i] = i;   } } I think there are no aliasing among pointers such as 'a', 'b' and 'buf'

On Monday 18 August 2008 17:21, Chris Lattner wrote: > On Aug 18, 2008, at 3:19 PM, David Greene wrote: > > I'm not quite understanding how one would use the existing alias > > analysis > > framework to represent a flow-sensitive analysis. > > Yep, the current infrastructure isn't set up to support this. > > I haven't seen a real world case where flow

On Aug 18, 2008, at 3:19 PM, David Greene wrote: > I'm not quite understanding how one would use the existing alias > analysis > framework to represent a flow-sensitive analysis. Yep, the current infrastructure isn't set up to support this. I haven't seen a real world case where flow sensitive AA is useful. Normally, the conversion to SSA form is sufficient. Can you

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >

On 2/27/13 11:21 AM, Arnold Schwaighofer wrote: > On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Nuno and Arnold: >> >> Thank you all for the input. >> >> Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. >> A clique is statically or dynamically allocated

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

On Monday 18 August 2008 17:48, David Greene wrote: > > Normally, the conversion to SSA form is sufficient. Can you talk > > about cases where this matters to you? > > Mostly it involves tying into our memory dependence analysis which > annotates things on program points. I need a way to translate back > to our optimizer data structures. > > So it's not

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction

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

On Aug 22, 2008, at 4:49 PM, John Regehr wrote: > Has anyone quantified the optimizations afforded by undefined signed > overflow? I'd expect that the benefits are minimal for most codes. In most cases, I agree. But for codes that depend heavily on dependence analysis, I would think that being conservative with index expressions would really kill any disambiguation capability and

> before and it hurts about 3-5 without high level loop > opts/vectorization on. With them on, they do roughly nothing in the > presence of -fwrapv because you can't determine bounds of any non > trivial loop. Very interesting, thanks! Before hearing this I'd have said that Java-style overflow is the right language design, but if this makes loop optimizations impossible

On Sun, Aug 24, 2008 at 6:28 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

>> One nit-pick, I see that some of the interfaces use tons of parameter, >> which is something I'd like reduce for ease of use. > >Right. It was my concern as well, but I eventually decided to write it >this way. Feel free to change it. > As we are speaking about modifying the lib, here are two things I would like to modify/add in it: - Replacing depedency

>Polyhedral representations are powerful but somewhat expensive to >construct and simple dependence tests don't construct them. Forcing >all dependence test results to go through them would be overkill. >Also, many loop transforms, e.g., loop interchange, don't need the >polyhedral info, just direction vectors. You could instead provide >both direction