similar to: Question about basic-aa's assumptions

Hello all, I observed that BasicAA alias query returns PartialAlias between different fields of a structure. Following is the test program and -print–all-alias-modref-info output: --- ; test.ll target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %"type" = type { [10 x i32], i64 } define void

Hi, I am a newbie to llvm. I am wondering what approach is used when coming out of SSA form. I also appreciate pointers on where to look in the source code for this phase. Best regards, Ram Ramshankar -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120824/87feb1d3/attachment.html>

Hi RamShankar, On top of Rafael mentioned ,Please check with lib/CodeGen/StrongPHIElimination.cpp and the papers like Budimlic, et al. Fast copy coalescing and live-range identification. // In Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language // Design and Implementation (Berlin, Germany, June 17 - 19, 2002). // PLDI '02. ACM, New York, NY, 25-32. Boissinot,

Hi, We've seen a similar case recently, where BasicAA returns PartialAlias for the access of two different fields of a structure. We noticed this since Lint complained about it when checking for aliasing beteen "noalias" attributed parameters: opt -S -lint ./alias.ll gave Unusual: noalias argument aliases another argument on the (silly) function: %rec7 = type { i16, i16, i16

Hi, We are proposing a loop fusion pass that tries to proactive fuse loops across function call boundaries and arbitrary control flow. http://reviews.llvm.org/D7008 With this pass, we get 103 loop fusions in SPECCPU INT 2006 462.libquantum with rate performance improving close to 2.5X in x86 (results from AMD A10-6700). I took some liberties in patching up some of the code in

----- Original Message ----- > From: "Adam Nemet" <anemet at apple.com> > To: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Saturday, January 17, 2015 12:20:55 AM > Subject: Re: [LLVMdev] proof of concept for a loop fusion pass > > > On Jan 15, 2015, at 4:22 PM, Ramanarayanan,

On 24 August 2012 02:27, Ramanarayanan, Ramshankar <Ramshankar.Ramanarayanan at amd.com> wrote: > Hi, > > > > I am a newbie to llvm. I am wondering what approach is used when coming out > of SSA form. I also appreciate pointers on where to look in the source code > for this phase. > lib/CodeGen/PHIElimination.cpp is probably what you want. > > Best regards,

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is

Oh m sorry for that mistake as I had points to in mind. But still what about the following prog: int main() { int *i,*j,k; i=&k; j=&k; k=4; printf("%d,%d,%d",*i,*j,k); return 0; } here too i dont get <i,j> alias each other. Duncan Sands wrote: > Hi ambika, > >> main() { >> int i,*k; >> k =

Hi Ambika, > Oh m sorry for that mistake as I had points to in mind. > But still what about the following prog: > > int main() > { > int *i,*j,k; > i=&k; > j=&k; > k=4; > printf("%d,%d,%d",*i,*j,k); > return 0; > } > > > here too i dont get <i,j> alias each other. how are you

Thanks so much for your feedback Simon. I am not sure that what I am proposing here is at odds with what you're referring to (here and in the PR you linked). The key difference AFAICT is that the pattern I am referring to is probably more aptly described as "reducing scalarization" than as "vectorization". The reason I say that is that the inputs are vectors and the output

I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is done first on each file and then at linking phase. Wouldn't it be a better alternative to delay inlining decisions until the link stage? Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120829/dda45c1c/attachment.html>

Hi, Richard, Your decompose vector patch works perfect on my site. Unfortunately, I still get stupid code because llvm '-dse' fails followed by 'decompose-vector' . I read the DSE code and it is definitely capable of eliminating unused memory stores if its AA works. I don't think basic AA works for me. I found my program have complex memory accesses, such as bi-dimentional

----- Original Message ----- > From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 11:00:39 AM > Subject: RE: [LLVMdev]

If -simd option is specified opt could do validity checks, dependency analysis and such and recognize that a loop can be executed in parallel and as the -simd option is specified, convert the data types to vector instructions and add the scaling factor to the loop's iterators. Following this there can be an early machine function pass that sets up processor specific value in all of

It's been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been

Absolutely. We do it for scalars, so it would likely be a matter of just extending it. But that is one example. The issue of extracting elements, performing an operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig

I have added a few PPC-specific DAG combines in the past that follow this pattern on specific operations. Now that it appears that this would be useful to do on yet another operation, I'm wondering what people think about doing this in the target-independent DAG Combiner for any legal/custom operation on the target. TL; DR; The generic pattern would look like this: (build_vector (op

Hi! I'm currently working on developing a new technique for alias analysis and wish to know how to compare it's results to the results that LLVM gets. The algorithm I have operates on LLVM assembly (I wrote the analysis in Haskell, so unfortunately I can't embed it into LLVM very easily). I tried using the option to print alias sets, but I'm not quite sure how to interpret the

On Wed, Aug 29, 2012 at 12:11 AM, Ramanarayanan, Ramshankar <Ramshankar.Ramanarayanan at amd.com> wrote: > I am wondering how O4 vs O3 do inlining. With O4 it looks like inlining is > done first on each file and then at linking phase. Wouldn’t it be a better > alternative to delay inlining decisions until the link stage? Yes and no. Yes in the sense that you may make some better