search for: pr14241

Hey Preston, I wanted to let you know that we found a really serious problem with DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in assumption that the base pointer of the GEPs it inspects are loop invariant. It appears to only do analysis on the subscripts. This is especially important for LLVM because C++ code (compiled through Clang) very frequently expresses loops as pointer loops r...

...ot;preston briggs" <preston.briggs at gmail.com> > Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 2, 2012 12:56:53 PM > Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 > > On 11/02/2012 10:21 AM, Preston Briggs wrote: > > > > My initial guess is that a conservative fix is quick and small > > (make > > sure the underlying pointers are loop invariant, otherwise give > > up). A > > better approach would be to somehow turn c...

On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked

...riggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November 2, 2012 12:56:53 PM >> Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 >> >> On 11/02/2012 10:21 AM, Preston Briggs wrote: >>> >>> My initial guess is that a conservative fix is quick and small >>> (make >>> sure the underlying pointers are loop invariant, otherwise give >>> up). A >>> better approach w...

...riggs at gmail.com> >>> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing >>> List" <llvmdev at cs.uiuc.edu> >>> Sent: Friday, November 2, 2012 12:56:53 PM >>> Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 >>> >>> On 11/02/2012 10:21 AM, Preston Briggs wrote: >>> >>>> >>>> My initial guess is that a conservative fix is quick and small >>>> (make >>>> sure the underlying pointers are loop invariant, otherwise give >>>&...

Hi Chandler, Thanks for writing. Could you give me some C (or C++) for an illustrative example. I think I understand your concern, but I'd like to be sure. Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121102/88c02212/attachment.html>

On 02.11.2012, at 15:53, Preston Briggs <preston.briggs at gmail.com> wrote: > Hi Chandler, > > Thanks for writing. > Could you give me some C (or C++) for an illustrative example. > I think I understand your concern, but I'd like to be sure. Hi Preston, The bug report at http://llvm.org/bugs/show_bug.cgi?id=14241 has more details, including a C++ test case. - Ben

I see, thanks Ben. So yes, I certainly misunderstood (more likely "misunderstand") how things work. My initial guess is that a conservative fix is quick and small (make sure the underlying pointers are loop invariant, otherwise give up). A better approach would be to somehow turn code like the example into array references that can be analyzed. I'll need to think about this and do