similar to: (no subject)

# How do I make from a SpatialGridDataframe a normal data frame? If I do this in package gstat: library(gstat) g.dummy <- gstat(formula = z~1, locations = ~x+y, dummy = TRUE, beta = 0, model = vgm(1,"Exp",15), nmax = 20) set.seed(1) iso <- predict(g.dummy, newdata = xy, nsim = 10) gridded(iso) = ~x+y # spplot(iso,main="isotropic") # not essential for this question # I

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

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

This is my first message to the list. Hello everybody! I just wanted to let you know that I submitted a couple of patches for two features that you might find them of interest. The first one adds support for unparsed responses to Facebooker::Session and Facebooker::Service models. This allows to use the Facebooker::Session.post method to obtain a plain response from the Facebook API, useful for

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

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

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

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

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

On Thursday 03 April 2008 22:00:34 Dan Gohman wrote: > However, for people just interested in post-regalloc scheduling and > VLIW packing and similar things, MemOperands aren't the only approach. > A potentially better way to do this would be to extend MachineInstrs > to preserve the chain dependencies from the SelectionDAG. the selection dag may already contain unnecessary

> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Note that the? * -> LaTex -> PDF rendered version looks a bitnicer. Ah yes, that does indeed look quite a bit nicer. > I wrote the function and that help page originally. And thank you for doing so. It is a wonderful function. (0 sarcasm here). > For that reason,

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 >

Funny I just ran into a situation where the imprecise information inhibits a coalescing. If you have made changes related to this, I'd love to have it. Thanks, Evan On Apr 7, 2008, at 10:52 AM, Evan Cheng wrote: > > On Apr 2, 2008, at 5:09 PM, David Greene wrote: > >> Why does LiveInterval::MergeInClobberRanges set the definition index >> as unknown? Why would the

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

Hello, I'm working on an application that would benefit from knowing the weight of a basic block, as in "fraction of the program's execution time spent in this block". Currently, I'm computing this using the block's frequency from BlockFrequencyInfo, relative to the function's entry block frequency, and scaled by the function's entry count. This is also the

On Apr 16, 2012, at 11:50 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Dan, > >> I realize that some of these thoughts apply equally to the >> prior !fpaccuracy metadata that's been around a while, but I >> hadn't looked at it closely until now. >> >> The !fpmath metadata violates the original spirit of >> metadata, which is that

On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: > Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >> 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

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

We were a little imprecise in our original announcement with regards to moving away from freedesktop.org, which seems to have caused some confusion. We are only moving away from the freedesktop.org infrastructure. NOT the standards. By moving away from freedesktop.org, we are: - Shutting down bug-submission on bugs.freedesktop.org. We will be using bugs.opencompositing.org which will soon be