similar to: [AssumeBundles] ValueTracking cannot use alignment assumptions?

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

Hi Peter, Thanks for the reply. I agree that the base class vtable may be not referenced by a derived class. However, the vtable of a derived class has to reference its parent type_info, and so having type_info internalized means that the class is final, doesn’t it? Thanks, Nikolai From: Peter Collingbourne [mailto:peter at pcc.me.uk] Sent: Wednesday, December 6, 2017 4:36 AM To: Gainullin,

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

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

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is

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

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

On 17 June 2014 06:41, Eli Bendersky <eliben at google.com> wrote: > On Tue, Jun 17, 2014 at 1:38 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Chandler Carruth wrote: >> >>> This seems fine to me, but I'd like to make sure it looks OK to Nick as >>> well. >>> >> >> I strongly prefer baking in knowledge about the

Chandler Carruth wrote: > This seems fine to me, but I'd like to make sure it looks OK to Nick as > well. I strongly prefer baking in knowledge about the intrinsics themselves into the passes if possible. Metadata will always be secondary. Separately, should value tracking look use range metadata when it's available? Absolutely. I think it should apply to all CallInst not just

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

On Tue, Jun 17, 2014 at 2:33 PM, Jingyue Wu <jingyue at google.com> wrote: > Hi Eric, > > In the IR, besides "target datalayout" and "target triple", we have a > special "target cpu" string which is set by the Clang front-end according to > its -target-cpu flag. We also write a Module::getTargetCPU() method to > retrieve this string from the

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 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.

>> I realise that the DataTypes.h.in part might be controversial. Also, >> there's probably a better place to put it, but I'm not sure where. > > I didn't apply this part. What problems does it cause to not have > this? Can we fix uses of max and min? I get these errors in lib: .../lib/Analysis/ValueTracking.cpp:162: error: no matching function for call to

Hi all, I came across an issue caused by the Call-Graph Simplify Pass. Here is a a small repro: ``` define double @foo(double %a1, double %a2, double %a3) #0 { entry: %a_mul = fmul double %a1, %a2 %a_cmp = fcmp ogt double %a3, %a_mul br i1 %a_cmp, label %a.then, label %a.end a.then: %a_div = fdiv double %a_mul, %a3 br label %a.end a.end: %a_factor = phi double [ %a_div, %a.then ],

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

[+current llvm-dev address] On 03/15/2017 09:23 AM, Hal Finkel wrote: > Hi Samuel, > > What are you taking about? ;) > > The only way to get a SIGFPE from a floating-point division by zero is > to modify the floating-point environment to enable those exceptions. > We don't support that (*). In the default (supported) environment, > floating point division is well

Eric Christopher wrote: > How are you trying to call it? Do you have a DataLayout? In test/Analysis/ValueTracking/memory-dereferenceable.ll, just change byval to dereferenceable(8), and %dparam won't match (see lib/IR/Value.cpp:521 for the logic that is supposed to fire). How do I get it to pass? I tried introducing a target-triple and target-datalayout, but it didn't help.

It’s true, I am working on this. I have committed the initial patch to add constrained intrinsics for the basic FP operations. This has the desired effect of preventing optimizations that would violate strict FP semantics with regard to rounding mode and exception status, but it also prevents many safe optimizations. Later this year I’ll be going through the code base and trying to teach

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the