similar to: [LLVMdev] finding where a Value was initially assigned

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:

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

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

Hello, This patch fixes PR2218. However, I'm not pretty sure that this optimization should be in MemCpyOpt. I think that GVN is good place as well. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218.patch Type: application/octet-stream Size: 6146 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

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:

Scott Ricketts wrote: > I would like to instrument certain function calls with a function call > of my own that takes some of the same arguments. For example, I would > like to instrument calls to free with some function foo, so the C code > would look like: > > foo(myarg1, myarg2, ptr); > free(ptr); > > The problem occurs when I grab the arg from the free function and

Hi Everyone, I asked a question on the dev list related to the topic to which John Criswell and Jeremy Lakeman kindly provided some valuable insight. I'm still stuck on the issue and i'm hoping i didn't phrase the question well enough. I have a *foo.c* file that is : *#include <stdio.h>* *int foo(int a, int b){* * return a+b;* *}* *int main() {* *int x=foo(3,1); *

Duncan, thanks for your answer! > In order to perform this transform the optimizers would have to work out > that sample does not modify any global state.  This cannot be done without > knowing the definition of sample, but you only provide a declaration. Which is why I am trying to supply this additional information in a custom alias analysis pass, but it doesn't seem to work. (The

Hello, I have been using the USE class to access the use-def chains of different values. However, what I have noticed is that the set of users of a particular value is limited for the appearance of that variable in the current function. How can I get the interprocedural use of a particular value? For example, if a variable *a* is used as an argument in a function call *foo*, the USE analysis

I would like to instrument certain function calls with a function call of my own that takes some of the same arguments. For example, I would like to instrument calls to free with some function foo, so the C code would look like: foo(myarg1, myarg2, ptr); free(ptr); The problem occurs when I grab the arg from the free function and try to pass it to foo... if (isCallToFree(&I)) { Value*

Hi Anton > > > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > > 123). > > I was diging in doxygen documentation but I really can't see the easy way > to > > compare those instructions and again finish with reinvented (but working) > > wheel ;). > Ah, sorry. I missed that you're doing variadic calls, not casting >

Hi, Artur > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > 123). > I was diging in doxygen documentation but I really can't see the easy way to > compare those instructions and again finish with reinvented (but working) > wheel ;). Ah, sorry. I missed that you're doing variadic calls, not casting variadic function to definite ones. I think you

Hi Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value

On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Going to keep this RFC short and to the point: >> >> TerminatorInst doesn't pull its weight in the type system. There is >> essentially a single

On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches to

On Thu, May 17, 2018 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Going to keep this RFC short and to the

Hello, > So, looking for type of callee (not result, but function type!) you'll > obtain the > real "signature" of callee and if you'll strip all pointer cast you'll > obtain the "declaration" (=variadic) type of the callee. Maybe I misunderstood something but I just get the variadic declaration not the real "signature", like this: const

Thanks for your reply. Yes, I was about to recurse over the use list of the argument in the called function. I did not want to pursue that because with this solution, I am going to implement the interprocedural part myself and was wondering if that was not already done. I was not also 100% sure that this will work for any type of arguments. If, based on your response, this is my only solution