search for: imprecision

# 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)

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

Hi, I am new to MemorySSA and wanted to understand its capabilities. Hence I wrote the following program (test.c): int N; void test(int *restrict a, int *restrict b, int *restrict c, int *restrict d, int *restrict e) { int i; for (i = 0; i < N; i = i + 5) { a[i] = b[i] + c[i]; } for (i = 0; i < N - 5; i = i + 5) { e[i] = a[i] * d[i]; } } I compiled this program using

On Tue, Dec 19, 2017 at 9:10 AM, Siddharth Bhat via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I could be entirely wrong, but from my understanding of memorySSA, each > def defines an "abstract heap state" which has the coarsest possible > definition - any write will be modelled as a "new heap state". > This is true for def-def relationships, but

...nction, better than the entry count. - This scheme "preserves mass" in that all samples of a function are taken into account. The samples in a BB are compared to samples in the entire function, rather than a few (arbitrarily) selected samples from the entry block. - The computation avoids imprecision from multiplying by small numbers. Disadvantages? - BlockFrequencyInfo needs to keep track of the total frequency in a function. - BlockFrequencyInfo would probably scale the frequencies w.r.t. that total, rather then the maximum frequency. This loses a few bits of precision Note that the entry...

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

Hi Alex, This has been very recently fixed by Hal. See http://reviews.llvm.org/rL270771 Adam > On Jun 4, 2016, at 3:13 AM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello. > 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

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

I did few transformation in Instruction *InstCombiner::visitFDiv() in an attempt to remove some divs. I may 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

I remember why I didn't implement this rule in Instcombine. It add one instruction. So, this xform should be driven by a redundancy eliminator if you care code size. On 8/8/13 10:13 AM, Shuxin Yang wrote: > I did few transformation in Instruction *InstCombiner::visitFDiv() in > an attempt to remove some divs. > I may miss this case. If you need to implement this rule, it is >

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

> This is not true. The mathematically correct result for sqrt might not be a representable 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

Hi Alex, I think the changes you want are actually not vectorizer related. Vectorizer just uses data provided by other passes. What you probably might want is to look into routine Loop::getStartLoc() (see lib/Analysis/LoopInfo.cpp). If you find a way to improve it, patches are welcome:) Thanks, Michael > On Jun 3, 2016, at 6:13 PM, Alex Susu <alex.e.susu at gmail.com> wrote: >

...ll loops. This has the advantage of being already implemented and easy to upstream, but would introduce a capped N^2 algorithm and thus a performance cliff. It might be worth upstreaming this with the threshold defaulted to 0 (i.e. nop) just as a testing mechanism for identifying places AST's imprecision is hurting us. >> >> Option 2 - As a variant of option 1, we can keep track of potentially clobbering instructions seen during a single walk of the loop. With this, the above N^2 algorithm becomes #L*#S, and we can easily bound the maximum number of clobbering instructions we track. I...

...oops. This has the advantage of being already implemented and easy to upstream, but would introduce a capped N^2 algorithm and thus a performance cliff. It might be worth upstreaming this with the threshold defaulted to 0 (i.e. nop) just as a testing mechanism for identifying places AST's imprecision is hurting us. Option 2 - As a variant of option 1, we can keep track of potentially clobbering instructions seen during a single walk of the loop. With this, the above N^2 algorithm becomes #L*#S, and we can easily bound the maximum number of clobbering instructions we track. I think this is...

Hi all, I'm a 3rd year CSE B.Tech student and have been studying LLVM since the past year. I have written a pass for doing register allocation as part of my course project and have also been studying LLVM code 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

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

I believe we were under the impression that InstCombine, as a canonicalized/optimizer, should not increase code size but only reduce it. Minor aside, but you don't need all of fast-math for the IR, just the "arcp" flag, which allows for replacement of division with reciprocal-multiply. On Aug 8, 2013, at 10:21 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > I remember