similar to: Speculative execution of FP divide Instructions - Call-Graph Simplify

Displaying 20 results from an estimated 1000 matches similar to: "Speculative execution of FP divide Instructions - Call-Graph Simplify"

2017 Mar 15
2
Speculative execution of FP divide Instructions - Call-Graph Simplify
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 ],
2017 Mar 15
2
Speculative execution of FP divide Instructions - Call-Graph Simplify
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
2014 Sep 19
2
[LLVMdev] More careful treatment of floating point exceptions
Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey
2015 Sep 08
2
UB and known bits
On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying
2015 Mar 16
4
[LLVMdev] possible addrspacecast problem
Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as
2014 Jun 17
5
[LLVMdev] Attaching range metadata to IntrinsicInst
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
2014 Jun 16
3
[LLVMdev] Attaching range metadata to IntrinsicInst
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
2014 Jun 17
4
[LLVMdev] Attaching range metadata to IntrinsicInst
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
2017 Dec 14
2
[RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
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
2020 Nov 18
2
[AssumeBundles] ValueTracking cannot use alignment assumptions?
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
2008 Sep 16
2
Setting user colors in barchart
Dear R Users, I have a basis question regarding the use of color in the lattice package. I read the ?barchart help page and searched the R archives but could not understand how to do it. I just need to plot a barchart using specific colors for my groups, e.g. green and red instead of the default lattice colors. How do I do that? If I say: barchart(x ~ a_factor, groups=my_groups,
2014 Jun 17
3
[LLVMdev] Attaching range metadata to IntrinsicInst
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
2014 Jun 17
2
[LLVMdev] Attaching range metadata to IntrinsicInst
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
2017 Dec 14
3
[RFC] Add TargetTransformInfo::isAllocaPtrValueNonZero and let ValueTracking depend on TargetTransformInfo
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
2009 Mar 06
1
[LLVMdev] CaptureTracking.h?
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
2015 Feb 09
2
[LLVMdev] DataLayout missing in isDereferenceablePointer()
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.
2009 Jan 19
0
[LLVMdev] cygwin build patch
On Jan 19, 2009, at 7:44 AM, Jay Foad wrote: > LLVM doesn't build out of the box on Cygwin, because Cygwin defines > uint32_t as "unsigned long" rather than "unsigned int". > > The attached patch allows me to build head of svn (rev 62510) on > Cygwin using GCC 4. Can this be committed please? Thanks applied:
2009 Jan 19
2
[LLVMdev] cygwin build patch
LLVM doesn't build out of the box on Cygwin, because Cygwin defines uint32_t as "unsigned long" rather than "unsigned int". The attached patch allows me to build head of svn (rev 62510) on Cygwin using GCC 4. Can this be committed please? 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
2014 Sep 25
2
[LLVMdev] More careful treatment of floating point exceptions
Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still
2011 Feb 10
1
[LLVMdev] PR9112
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