similar to: [LLVMdev] [PATCH] PR2218

On Jul 22, 2009, at 1:37 PM, Jakub Staszak wrote: > Hello, > > This patch fixes PR2218. Very nice. Are you sure this fixes PR2218? The example there doesn't have any loads in it. > However, I'm not pretty sure that this optimization should be in > MemCpyOpt. I think that GVN is good place as well. Yes, you're right. My long term goal is to merge the relevant

Hello, Sorry for my stupid mistakes. I hope that everything is fine now. This patch fixes PR2218. There are no loads in example, however "instcombine" changes memcpy() into store/load. Regards, Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-2.patch Type: application/octet-stream Size: 6525 bytes Desc: not available URL:

Hello, I fixed my patch as you asked. Sorry for the delay, I'd been working on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html ) I hope that everything is fine now. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-3.patch Type: application/octet-stream Size: 7511 bytes Desc: not available URL:

On Jul 25, 2009, at 4:48 PM, Jakub Staszak wrote: > Hello, > > Sorry for my stupid mistakes. I hope that everything is fine now. > This patch fixes PR2218. There are no loads in example, however > "instcombine" changes memcpy() into store/load. Hi Jakub, Sorry for the delay, I'm way behind on code review. Generally if you respond quickly, I'll remember

On Sep 2, 2009, at 1:07 AM, Jakub Staszak wrote: > Hello, > > I fixed my patch as you asked. Sorry for the delay, I'd been working > on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html > ) > > I hope that everything is fine now. Hey Jakub, Thanks for working on this again, one more round :) Please merge the three testcases into one

On Sep 2, 2009, at 3:15 PM, Chris Lattner wrote: > Please merge the three testcases into one file. We added a new > FileCheck tool which allows you to check for the exact sequence of > instructions expected, which also allows the tests to be merged into > one file. > > +/// MemCpyOpt::pointerIsParameter - returns true iff pointer is a > parameter of > +/// C call

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > Hi All, > > I have a question on ConstantExpressions and llvm intrinsic > memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C > programs that I am compiling using clang frontend, the call to memcpy > instrinsic looks like the following > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast

My pass is looking at StoreInsts acting on global variable that happen to be function pointers. From these StoreInsts I would like to get useful information(the function used if a direct assignment, function pointer used, etc) from the getValueOperand() method. Looking through several examples I see that this can return several things like: GlobalVariable, Function, LoadInst or BitCastInst

Hi, I'm a PhD student doing phase ordering as part of my PhD topic and I would like to ask some questions about LLVM. Executing the following command to see what passes does OPT execute when targeting a SPARC V8 processor: /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/llvm-as < /dev/null | /opt/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/opt -O3 -march=sparc -mcpu=v8

On 09/27/2018 12:24 AM, Chris Lattner via llvm-dev wrote: On Sep 26, 2018, at 11:55 AM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote: As suggested in the bug, if we were to rewrite these passes to use MemorySSA, this bottleneck would go away. I rebased a patch to do that for DSE, but finishing it off and enabling it by default is probably out of scope for me.

On Sat, Nov 22, 2014 at 11:09 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Qiuping, > > If I'm reading the IR correctly, what you have is a > GetElementPtrConstantExpr [1]. It subclasses from llvm::Constant. > If you want the same code to handle GetElementPtrConstantExpr *and* GetElementPtrInst, you can use GEPOperator. > > Thanks, > --

Hi, in a recent review [0], Florian Hahn helped me to realize something that was rather surprising to me: The widely popular and very useful function llvm::Value::stripPointerCasts() can return a value with a different bit pattern than the input. Now, I think this should not be the case but I want the hear other opinions. Before I go on, please not that there is at least one location in

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

> On Dec 14, 2018, at 2:44 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote: > > Do you have an opinion on which should be the default? > > -Hal > > Not particularly. The current name sounds to me like it would strip any casts it possibly can. Maybe most uses should now be converted to a newly named stripTrivialPointerCasts? -Matt -------------- next part

What LoopVectorize.cpp has are the following. Each function may have to have a separate consolidation discussion. I'm bringing up getpointerOperand() since I actually found multiple instances defined/used. DependenceAnalysis.cpp has isLoadOrStore(). LoopAccessAnalysis.cpp has getAddressSpaceOperand(). I'm sure there are others that might be worth discussing within this thread or a follow

I have the following prototype for a function: void bkp_memory(char *, int); Inside my LLVM IR, I have a callsite looks like the following: tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind When I try to obtain its 1st argument and check whether it is a valid instruction, using: Instruction *Inst = dyn_cast<Instruction *>(I->getOperand(0)); it gives me a

On 2/10/20 2:35 PM, Alina Sbirlea wrote: > Hi, > > Here's a tentative patch of the changes for this: D74353 > <https://reviews.llvm.org/D74353>. I suppose that, as expected, it's invalidated less often this way. Given that it's generally stateless, does this really represent a cost savings?  -Hal > > Thank you, > Alina > > > On Mon, Feb 10,

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "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