similar to: [LLVMdev] [RFC] Intrinsic for declaring invariants

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Andrew Trick" <atrick at apple.com>, "Richard Smith" > <richard at

Hello everyone, I'm starting a new thread, as a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls

On Thu, Jul 17, 2014 at 5:31 PM, Philip Reames <listmail at philipreames.com> wrote: > 3. An "llvm.invariant" has zero code generation cost. Given that, a lot > of pattern matching and profitability heuristics will need adjusted to > ignore them. > FWIW, this has been the fundamental point of contention in the entire design. I've discussed this several times with

----- Original Message ----- > > > > On Sep 7, 2013, at 7:41 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > On Feb 7, 2013, at 10:58 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > As long as this is brainstorming time, I actually like the idea of > an > llvm.invariant intrinsic that the optimizers know to

On Sep 7, 2013, at 7:41 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> On Feb 7, 2013, at 10:58 PM, Hal Finkel < hfinkel at anl.gov > wrote: >> >> >> >> >> As long as this is brainstorming time, I actually like the idea of >> an >> llvm.invariant intrinsic that the optimizers know to ignore. I >> like >> it for other

On Aug 19, 2013, at 8:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> On Feb 22, 2013, at 6:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message ----- >>>> From: "Andrew Trick" <atrick at apple.com> >>>> To: "Hal Finkel" <hfinkel at anl.gov>

----- Original Message ----- > > > > On Aug 19, 2013, at 8:06 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > > On Feb 22, 2013, at 6:28 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > From: "Andrew Trick" < atrick at

<div style="FONT-FAMILY: Arial; COLOR: rgb(0, 0, 0); FONT-SIZE: 12px">Hello All,<br /><br />I'm trying to install KVM on a test CentOS 6 server, running the following command, and getting the following result. I suspect the repositories my system is trying to reach out to aren't carrying the packages for KVM, but I'm not sure.<br /><br />Not sure

On Mon, Aug 19, 2013 at 10:06 PM, Andrew Trick <atrick at apple.com> wrote: > Metadata is a better approach because it doesn’t interfere with > optimizations that are free to ignore it. > But in practice, they aren't going to be free to ignore it. If you have metadata which encodes an invariant (in the most general sense, lifetime instrinsics currently encode an invariant,

Hi, The range metadata can only be attached to LoadInst for now. I am considering extending its usage to IntrinsicInst so that the frontend can annotate the range of the return value of an intrinsic call. e.g., %a = call i32 @llvm.xxx(), !range !0 !0 = metadata !{ i32 0, i23 1024 } The motivation behind this extension is some optimizations we are working on for CUDA programs. Some special

That sounds like a bug, yes. Please file a bug? :) Roman On Wed, Nov 18, 2020 at 6:26 AM Bozhenov, Nikolai <nikolai.bozhenov at intel.com> wrote: > > Hello, > > As I can see, recently LLVM switched to using assume bundles to encode alignment information: https://reviews.llvm.org/rG78de7297abe2e8fa782682168989c70e3cb34a5c > > However, it seems that the ValueTracking cannot

Hello, As I can see, recently LLVM switched to using assume bundles to encode alignment information: https://reviews.llvm.org/rG78de7297abe2e8fa782682168989c70e3cb34a5c However, it seems that the ValueTracking cannot understand the new format. As an example, consider compilation of the following reproducer with clang-11 (old assume format) and clang-trunk (assume bundles): #include

Is there any particular reason that CaptureTracking.h isn't folded into ValueTracking.h? I was looking for the method to check whether a pointer would be captured and looked in ValueTracking.h, unaware that a new header had been created for that one method. Would anyone mind if I folded CaptureTracking into ValueTracking? Nick -------------- next part -------------- An HTML attachment was

Eh? How do you envision this? -eric On Tue, Jun 17, 2014 at 2:09 PM, Jingyue Wu <jingyue at google.com> wrote: > Hi Nick, > > That makes sense. I think a main issue here is that the ranges of these PTX > special registers (e.g., threadIdx.x) depend on -target-cpu which is only > visible to clang and llc. Would you mind we specify "target cpu" in the IR > similar

Hello, This simple patch fixes PR9112: Index: lib/Analysis/ValueTracking.cpp =================================================================== --- lib/Analysis/ValueTracking.cpp (revision 125281) +++ lib/Analysis/ValueTracking.cpp (working copy) @@ -593,6 +593,8 @@ // Otherwise take the unions of the known bit sets of the operands, // taking conservative care to avoid

Hi all! I'm new here, and would like to implement my own Loop Invariant Detection adding some more information on Quasi-Invariants. First, is there anything about Quasi-Invariants detection in LLVM I would missed? I've seen LICM using LoopInfo::isLoopInvariant for finding invariants. It seems that this method considers a Value invariant if: - it's an Instruction not presents in the

I have committed a fix for the panic that happened with the da(4) or cd(4) drivers configured and INVARIANTS turned on. Let me know if there are any problems/comments/questions. Ken ----- Forwarded message from "Kenneth D. Merry" <ken@FreeBSD.org> ----- From: "Kenneth D. Merry" <ken@FreeBSD.org> Date: Tue, 9 Sep 2003 17:40:40 -0700 (PDT) To:

Some optimizations depend on whether alloca instruction always has non-zero value. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has

Hi everyone, I posted some questions related to implementing inference of nsw/nuw flags based on known icmp results to Bug 30428 ( https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended that I engage a wider audience by coming here. The minimal context is the following, please see the bug report for more detail: > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. > 2.

Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has