similar to: [LLVMdev] Optimize away sqrt in simple cases?

That's a pretty seriously unsafe floating point optimization. It could be done in fast-math mode, but I doubt we currently do it. --Owen On Apr 23, 2013, at 1:12 PM, Erkki Lindpere <villane at gmail.com> wrote: > hi! > > I'm using LLVM 3.2. Does it optimize away llvm.pow(llvm.sqrt(x), 2) to `x` with any settings? I tried with llc -O3, but that didn't do it. >

Hello, Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen Anderson: > That's a pretty seriously unsafe floating point optimization. It could be > done in fast-math mode, but I doubt we currently do it. I just saw this thread and wonder why it's "seriously" unsafe? I see only one problematic corner case. For x >= 0.0 the result cannot lose precision. For x = NaN the

Thanks for the quick reply! I will keep the DIBuilder and Clang's CGDebugInfo as my reference for now. At the moment I want to stick with generating .ll -- it's somewhat easier for me to debug the output of my compiler that way, and I haven't programmed much in C/C++ for years -- mostly been a JVM guy. But at one point I may want to look into bindings or even creating a bootstrapped

Hi, I'm a newbie when it comes to compilers (and even close-to-machine coding), but recently started working on my own language and am using LLVM as the mid/backend. Currently I'm generating .ll files from a front-end written in Scala. The language is not really serious, just a way to learn more about compilers (and LLVM) and maybe serve as a base for further experiments. It's

Thanks for the reply On Fri, Jul 29, 2011 at 2:06 AM, David A. Greene <greened at obbligato.org>wrote: > Erkki Lindpere <villane at gmail.com> writes: > Ok. Do you ever need to grab the address of something on the stack? If > so you're going to need an alloca. AFAIK, it's the only way to generate > an address for a local object. This is by design of the IR and

Hi, I wanted to add debug info to my language (compiler written in Scala, outputs .ll files), but I found it really hard to do based on the documentation provided at http://llvm.org/docs/SourceLevelDebugging.html (I looked at the specific doc for LLVM 3.0 though) With LLVM 3.0, DI version 8 (which is documented there) seemed to work, except DW_TAG_auto_variable for which I used version tag 11

Erkki Lindpere <villane at gmail.com> writes: > I want to experiment with avoiding mutable state as far as I can. At > the moment there are no mutable variables -- only immutable value > types (numerics, bool, vectors, tuples) and I've been doing everything > in LLVM registers. The compiler doesn't generate a single alloca, load > or store at the moment. Ok. Do you

On Wed, Mar 20, 2013 at 2:21 PM, Erkki Lindpere <villane at gmail.com> wrote: > Hi, > > I wanted to add debug info to my language (compiler written in Scala, > outputs .ll files), but I found it really hard to do based on the > documentation provided at http://llvm.org/docs/SourceLevelDebugging.html(I looked at the specific doc for LLVM 3.0 though) > > With LLVM 3.0, DI

Am Dienstag, 23. April 2013, 22:50:51 schrieben Sie: > [...] > Giving more-than-expected precision can be just as bad for the user as less. > It tends to come up in situations where the optimization would break some > symmetry, the same way that aggressively forming FMAs can break user code. > [...] > > It boils down to the fact that giving excess precision in >

On Apr 23, 2013, at 7:15 PM, Stephen Lin <swlin at post.harvard.edu> wrote: >> 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. > > I think what Christoph is saying is that x will always be at least as > accurate as pow2(sqrt(x)),

> 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

On Apr 23, 2013, at 3:33 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Hello, > > Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen Anderson: >> That's a pretty seriously unsafe floating point optimization. It could be >> done in fast-math mode, but I doubt we currently do it. > > I just saw this thread and wonder why it's

On Apr 24, 2013, at 12:36 AM, Stephen Lin <swlin at post.harvard.edu> wrote: > By the way, I definitely believe you that this isn't a 100% safe > optimization, but I'm curious, is this really guaranteed here that c > will not be a non-zero finite value? I was under the impression that > FPU state could lead to slightly different results in these kinds of > cases, so

On 04/23/2013 10:50 PM, Owen Anderson wrote: > > On Apr 23, 2013, at 7:15 PM, Stephen Lin <swlin at post.harvard.edu> wrote: > >>> 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. >> >> I think what Christoph is

Hello everyone, The particular motivation for this e-mail is my desire for feedback on how to fix PR17758; but there is a core design issue here, so I'd like a wide audience. The underlying issue is that, because the semantics of llvm.sqrt are purposefully defined to be different from libm sqrt (unlike all of the other llvm.<libm function> intrinsics) (*), and because autovectorization

Hi Hal, all. I'm not sure why llvm.sqrt is 'special'. Maybe because there is a SSE packed sqrt instruction (SQRTPS) but not e.g. a packed sin instruction AFAIK. As mentioned in a recent mail to this list, I would like llvm.sqrt to be defined as NaN for argument x < 0. I believe this would bring it more into line with the other intrinsics, and with the libm result, which is

We upgraded a 64 bit server from Centos 4 to 5 and encountered some strange problems. Tcsh segfaulted irregurarily and emacs gave irregurarily strange error messages about regular expressions. Both problems disappeared when a 32-bit version was installed instead of the 64-bit. Ldconfig still occasionally segfaults. 64-bit servers where Centos 5 was installed from scratch have no problems. It is

Hello. I am curious why did you changed TableGen to allow in principle only writing ASM instructions in prefix notation. I ask because I personally use an assembly notation that is infix (I could use a simple preprocessor that changes prefix to infix). Just to mention: I found the solution to this - the following part of the code is responsible for this from

I guess this would establish a separate "namespace" of symbolic prefix operators, %*% being an example in the infix case. So you could have stuff like %?%, but for non-symbolic (spelled out stuff like %foo%), it's hard to see the advantage vs. foo(x). Those examples you mention should probably be addressed (eventually) in the core language, and it looks like people are already able

Martin, Jim can speak directly to his motivations; I don't claim to be able to do so. That said, I suspect this is related to a conversation on twitter about wanting an infix "unquote" operator in the context of the non-standard evaluation framework Hadley Wickham and Lionel Henry (and possibly others) are working on. They're currently using !!! and !! for things related to