similar to: [LLVMdev] Extending Intrinsic Functions

Thanks for your reply, Philip. You are right, when I use LLVM-3.8, the 'argmemonly' shows up. Previously, I use LLVM-3.7. I think idempotent is what I want. Can you tell me how to add idempotent attribute to the function? Thanks. Regards, Xiangyang 2016-03-24 14:30 GMT-07:00 Philip Reames <listmail at philipreames.com>: > > > On 03/24/2016 12:45 PM, Xiangyang Guo via

On 03/24/2016 12:45 PM, Xiangyang Guo via llvm-dev wrote: > Hi, > > When I define an intrinsic function with memory write permission, my > assumption is that we can either attach [IntrReadWriteArgMem] or [] to > the intrinsic function. Based on the comment of the source code , > "IntrReadWriteArgMem - This intrinsic reads and writes only from > memory that one of its

If int_guard_load returns a pointer based on the passed-in pointer, it captures it (at least according to the definition of "capture" which NoCapture uses). -Eli On Thu, Oct 6, 2011 at 2:26 PM, Zeng Bin <ezengbin at gmail.com> wrote: > It does not do anything. It is an abstract function which transforms a > pointer and returns another pointer of the same type. It does not

It does not do anything. It is an abstract function which transforms a pointer and returns another pointer of the same type. It does not visit memory or capture the pointer parameter. On Thu, Oct 6, 2011 at 2:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > > On Thu, Oct 6, 2011 at

On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: >> Hi all, >> >> There might be a bug in DeadStoreElimination.cpp. This pass eliminates >> stores backwards aggressively in an end BB. It does not check dependencies >> on stores in an end BB though.

On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: > Hi all, > > There might be a bug in DeadStoreElimination.cpp. This pass eliminates > stores backwards aggressively in an end BB. It does not check dependencies > on stores in an end BB though. For example, in this code snippet: >   ... > 1.  %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre,

Thanks Eli. I will try your solution, but then, what is the difference between [IntrReadArgMem] and [IntrReadMem] when specifying an intrinsic ? It seems that both options specify that a function is 'readonly' (maybe the difference is not well supported for then moment ?) Julien > Dead store elimination is that pass that could do the optimizations in > question. The second

I'd like to clarify the meaning of "Intr*Mem" flags used in intrinsics definitions. If an intrinsic does not access memory but read and write control registers, what flag should I apply in this case: IntrNoMem or IntrReadWriteArgMem or nothing? Thanks. -- Simon

So I removed the 'tail' from the call and try out different properties: - IntrNoMem: memset() and the intrinsic are both optimized away as expected - IntrWriteMem: memset() optimized away by DSE but the intrinsic isn't. I would expect both to be removed, since the intrinsic is now also a dead store. - IntrReadMem: memset() and the intrinsic are both optimized away *unexpectedly* (CSE

Hi, When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set,

Hi all, There might be a bug in DeadStoreElimination.cpp. This pass eliminates stores backwards aggressively in an end BB. It does not check dependencies on stores in an end BB though. For example, in this code snippet: ... 1. %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, %entry.for.end_crit_edge ], [ %sum.safe_r42, %for.body ] 2. %call9 = call i32 @gettimeofday(%struct.timeval* %end,

On Tuesday 24 March 2009 10:43, Chris Lattner wrote: > On Mar 23, 2009, at 5:56 PM, David Greene wrote: > > Is it legal to do something like a !strconcat on a non-string > > entity? That > > is, is there some operation that will let me do this (replace > > SOME_CONCAT with > > an appropriate operator): > > I don't get it, can you try a simpler example on

Hey guys, There seems to be an inconsistency between mask operand types for the AVX512 intrinsics. The mask instruction intrinsics expect a v16i1 for the mask operands: > def int_x86_kadd_v16i1 : GCCBuiltin<"__builtin_ia32_kaddw">, > Intrinsic<[llvm_v16i1_ty], [llvm_v16i1_ty, llvm_v16i1_ty], > [IntrNoMem]>; But other

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even compile I think, with not all

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

> On Mar 24, 2016, at 12:45 PM, Xiangyang Guo via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes

Hi, All, Suppose I define one memory read only intrinsic function "foo" in Intrinsics.td like this def int_foo : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrReadMem]>; Suppose I have the following IR, which means the intrinsic function "foo" is called 10 times in a loop. Since the parameters of function "foo" are invariant and the function

Thanks for your reply, escha, Yes, -loop-rorate makes it work. Regards, Xiangyang 2015-12-01 12:48 GMT-05:00 <escha at apple.com>: > > > On Dec 1, 2015, at 9:30 AM, Xiangyang Guo via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, All, > > > > Suppose I define one memory read only intrinsic function "foo" in >

Ok, now I think I've found a bug: Consider this C code: void bar(int b) { int a[10]; memset(a, b, 10); } which generates this IR code: define dso_local void @bar(i32 %b) #0 { entry: %b.addr = alloca i32, align 4 %a = alloca [10 x i32], align 16 store i32 %b, i32* %b.addr, align 4 %arraydecay = getelementptr inbounds [10 x i32], [10 x i32]* %a, i64 0, i64 0 %0 = bitcast i32*

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,