search for: imprecise

# PROBLEM WITH ABLINE # I have a question about a seemingly imprecise abline figure which I have come accross now a few times. # After reading variables a and b... a<-c(3729,1796,1956,5177,3201,3138,4265,3042,3745,2060,5713,6811,4184,1221,4700,3171,8913,5565,5500,2428,4841,10428,11197,5946,2783,4842) b<-c(7,3.4,4.8,11.2,7,5,8.2,6.2,7.4,7.4,18.4,13.8,8.8,3.6,7.2...

After upgrading to R-2.3.1 on Linux Redhat, I was suprised by this: R> x <- c(721.077, 592.291, 372.208, 381.182) R> sum(x) - 2066.758 [1] 4.547474e-13 Now I understand that floating point arithmetic is not precise, but 1) the result is exactly 0 in R-2.2.1 (patched) on the same machine, 2) .Machine$double.eps = 2.2e-16, so the error seems quite large. Also note I get the same

Hi all, Quoting <http://llvm.org/docs/LangRef.html#i_malloc>: The 'malloc' instruction allocates sizeof(<type>)*NumElements bytes of memory from the operating system and returns a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated. Obviously this does not say that the default for NumElements

I was just playing around in irb and noticed that while BigDecimal + Integer => BigDecimal, BigDecimal + Float => Float. Is there any reason for this? It seems inconsistent and means you have to check the class of any number you add to a BigDecimal, which looks very un-Ruby-like to me. Ashley

...n to be from the MemoryPhi node 4, which, in turn has one of its reaching definitions as 1 = MemoryDef(3). But this MemoryPHi node also has another reaching definition which is 2 = MemoryDef(4) which corresponds to the definition of array e in the second loop. This seems to make the MemorySSA form imprecise because it seems to indicate that the use of "a" in the second loop could be having a reaching definition from the definition of "a" in the first loop or the definition of "e" in the second loop (through the MemoryPhi). I would have expected only the first reaching def...

...new memorydef node. > > Yes, but MemoryUses can reach back past the nearest def, so that doesn't affect uses. The limitation here is deliberately done to keep it only requiring a single phi. All data from building this for years in GCC (which also moved from "precise" to "imprecise" for the same reason) told us that the massive amount of def-use chains you end up with from trying to model def-def relationships precisely was not worth it by far. (It degrades into putting N^2 variables into SSA, and attaching N variables to each def/use). With respect to that model, memo...

...by the function's entry count. This is also the computation that's done by getBlockProfileCount <https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/BlockFrequencyInfoImpl.cpp#L540> in lib/Analysis/BlockFrequencyInfoImpl.cpp. The problem is that this method can be extremely imprecise, because many functions have an entry count of zero. The entry count is computed from the number of profile samples in the entry block. Depending on the function's CFG, this count can be arbitrarily low even though the function is frequently called or hot. Here's an idea to address this. I...

On Thu, Aug 08, 2013 at 10:13:07AM -0700, Shuxin Yang wrote: > You should be very careful, reciprocal is very very very imprecise > transformation. Sometimes you will see big different > with and without this xform. What about constant %a, %b in this case? At least for power-of-two arguments, wouldn't it still be precise? Joerg

...gt; Mikhail, I come back to this older thread. > I need to do a few changes to LoopVectorize.cpp. > > One of them is related to figuring out the exact C source line and column number of the loops being vectorized. I've noticed that a recent version of LoopVectorize.cpp prints imprecise debug info for vectorized loops such as, for example, the location of a character of an assignment statement inside the respective loop. > It would help me a lot in my project to find the exact C source line and column number of the first and last character of the loop being vectorized. (impr...

For values above integer accuracy in floats, val - floor(val) might actually produce a value greater than 1. For such large floats, it's reasonable to be imprecise, but it's unreasonable for FRC to return a value that is not between 0 and 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouv...

...miss this case. If you need to implement this rule, it is better done in Instcombine than in DAG combine. Doing such xform early expose the redundancy of 1/y, which have positive impact to neighboring code, while DAG combine is bit blind. You should be very careful, reciprocal is very very very imprecise transformation. Sometimes you will see big different with and without this xform. On 8/8/13 9:25 AM, Chad Rosier wrote: > I would like to transform X/Y -> X*1/Y. Specifically, I would like to > convert: > > define void @t1a(double %a, double %b, double %d) { > entry: > %di...

...to implement this rule, it is > better done in Instcombine than in DAG combine. > Doing such xform early expose the redundancy of 1/y, which have > positive impact to neighboring code, > while DAG combine is bit blind. > > You should be very careful, reciprocal is very very very imprecise > transformation. Sometimes you will see big different > with and without this xform. > > On 8/8/13 9:25 AM, Chad Rosier wrote: >> I would like to transform X/Y -> X*1/Y. Specifically, I would like to >> convert: >> >> define void @t1a(double %a, double %b,...

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan relocations. It's also redundant with the (local_)unnamed_addr analysis already performed by LLVM. I implemented an alternative to this approach in clang and lld. It works by adding a section to e...

...value in floating point, so rounding may occur between the two steps. In that case, pow2(sqrt(x)) != x. > > --Owen I think what Christoph is saying is that x will always be at least as accurate as pow2(sqrt(x)), so it's only unsafe in so far as one's code is actually depending on an imprecise result. It's not an "as-if" optimization though, so it definitely would require "fast math" or something similar; however, it seems like it would be on the more benign side among optimizations that apply mathematical identities that are not necessarily identities on floats,...

...gt; Mikhail, I come back to this older thread. > I need to do a few changes to LoopVectorize.cpp. > > One of them is related to figuring out the exact C source line and column number of the loops being vectorized. I've noticed that a recent version of LoopVectorize.cpp prints imprecise debug info for vectorized loops such as, for example, the location of a character of an assignment statement inside the respective loop. > It would help me a lot in my project to find the exact C source line and column number of the first and last character of the loop being vectorized. (impr...

...and does not help with general aliasing collapse issue. It also requires every consumer of the AST interface to be updated to explicit check the "alias all" set. (Note: This could help other "unknown instruction" cases as well as readonly calls. It just doesn't solve the imprecise aliasing transitivity for known instructions.) >> >> Option 4 - We can split AST into two sets of alias sets. One set of set is based on aliasing ref behaviour, the other on mod behaviour. The rules for adding to the first set of sets are the existing AST rules. A load would only be a...

...does not help with general aliasing collapse issue. It also requires every consumer of the AST interface to be updated to explicit check the "alias all" set. (Note: This could help other "unknown instruction" cases as well as readonly calls. It just doesn't solve the imprecise aliasing transitivity for known instructions.) Option 4 - We can split AST into two sets of alias sets. One set of set is based on aliasing ref behaviour, the other on mod behaviour. The rules for adding to the first set of sets are the existing AST rules. A load would only be added to an mo...

...de sections related to SSA construction, dominance frontiers,etc. I also made some contributions to the Polly project. Currently I am interested in improving the existing alias analysis infrastructure as part of my GSoC-15 project. The current pointer analyses in LLVM (basicaa, cflaa etc.) compute imprecise information as none of them are flow-sensitive. The aim of my project is to implement a pass that computes more precise points-to pairs that is both flow-sensitive as well as context-sensitive. This method has been described in  Liveness-Based Pointer Analysis [http://www.cse.iitb.ac.in/grc/softwar...

Hi Alex, I'm not aware of efforts on loop coalescing in LLVM, but probably polly can do something like this. Also, one related thought: it might be worth making it a separate pass, not a part of loop vectorizer. LLVM already has several 'utility' passes (e.g. loop rotation), which primarily aims at enabling other passes. Thanks, Michael > On Feb 15, 2016, at 6:44 AM, RCU

...ment this rule, it is better done in Instcombine than in DAG combine. >> Doing such xform early expose the redundancy of 1/y, which have positive impact to neighboring code, >> while DAG combine is bit blind. >> >> You should be very careful, reciprocal is very very very imprecise transformation. Sometimes you will see big different >> with and without this xform. >> >> On 8/8/13 9:25 AM, Chad Rosier wrote: >>> I would like to transform X/Y -> X*1/Y. Specifically, I would like to convert: >>> >>> define void @t1a(double %a,...