similar to: [LLVMdev] Idempotent intrinsics

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 Fri, Jan 24, 2014 at 4:17 PM, Philip Reames <listmail at philipreames.com>wrote: > On 1/24/14 3:52 PM, Raul Silvera wrote: > > In include/llvm/IR/Intrinsics.td there is code to mark sqrt and several > other math intrinsics as "ReadOnly", even though they do not read memory. > > According to the comments this was done as an attempt to model changes > to

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

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.

I would be perfectly fine with Raul & Chandler's proposal, provide that clear documentation is added. The strong distinction between standard library calls and intrinsics is an important point for front end authors. The deliberate ignorance of floating point environment flags is entirely defensible, but needs to be documented clearly. We should also document which rounding mode

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

In include/llvm/IR/Intrinsics.td there is code to mark sqrt and several other math intrinsics as "ReadOnly", even though they do not read memory. According to the comments this was done as an attempt to model changes to the FP rounding mode. This is too conservative, and unnecessarily blocks transformations such as commoning and vectorization. I have heard from others that FP

As part of PhD research I integrated support for code generation of idempotent (re-executable) code regions into LLVM, along with a supporting IR-level analysis to identify and demarcate large "semantically" idempotent regions [1]. Some have expressed interest the code, so here is a link that contains some documentation and pointers to the source hosted on GitHub:

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

Hi all, I was wondering how to use variations of intrinsic functions that take a memory operand. Take for example the SSE4.1 pmovsxbd instruction. One variant takes two XMM registers, while another has a 32-bit memory location as source operand. The latter is quite interesting if you know you're reading from memory anyway, and if it's not 16-byte aligned. It looks like LLVM's

On 20/05/2010, at 3:01 AM, Chris Lattner wrote: > > On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > >> Hi all, >> >> I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the

On Fri, Aug 1, 2008 at 12:10 AM, Nicolas Capens <nicolas at capens.net> wrote: > I was wondering how to use variations of intrinsic functions that take a > memory operand. Often, for intrinsics where it matters, there's a variant of the intrinsic that takes a pointer operand that you can use, although it looks like there isn't one here. > Take for example the SSE4.1

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 May 19, 2010, at 3:13 PM, o.j.sivart at gmail.com wrote: >> >> Intrinsics should be optimized as well as instructions. In this specific case, these intrinsics should be marked readnone, which means that load/store optimization will ignore them. Dead code elimination will delete the intrinsic if it is dead etc. > > I understand that dead code elimination is able to delete

Hi all, I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: @global = global i32 0

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,

I'm working on a simple embedded language which runs via the JIT. I've reached the point of calling external functions. I'm finding that when the docs say that not all intrinsics are supported on all architectures, they're not kidding. For example, on my vanilla amd64 box running Linux, if I try to use llvm.ceil.f64, I get an unresolved symbol error ("Program used external

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

Hello, According to include/llvm/IR/Intrinsics.td, InstrReadMem property indicates that the intrinsic only reads from and does not write to memory. Does this mean that it can read anywhere in the memory? Because we already have 'InstrArgMemOnly' for intrinsics which only access memory that its argument(s) point(s) to. If 'InstrReadMem' really means read from anywhere in the

On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > Hi all, > > I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. > > If I have some sequence (> 1)