similar to: [LLVMdev] [PATCH] [ADT] APFloat - Fix sign handling for FMA results that truncate to zero.

Hi Mehdi, Thanks for the feedback. I think the comment is fine - the problem is just that the original conditional didn't exactly match it. With the addition of the underflow check I believe the condition now matches the comment: The sign is only tweaked if the result of the addition is exactly zero, rather than a small result that truncates to zero. CC'ing llvm-commits, where this email

This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }

> ... math errno ... I wouldn't recommend to anyone that they should rely on math errno (because I don't trust libraries to correctly support it). My goal here was to incorporate our existing support for it into the rest of what I'm trying to document. My understanding is that for clang this primarily controls whether or not we feel free to substitute intrinsics for recognized

APFloat is derived from C code using fixed width storage for the matntissa. When converting to C++ I changed it to variable- width storage for space efficiency and generality reasons. Unfortunately this leads to a complication during float->float conversions that I missed that isn't present when using fixed width storage. Dale - I think this solves the issue correctly whilst preserving

Hi Sanjay, You are right. I tried XL and gcc 4.8.2 for PPC and I also got multiply-and-add operations. I supported my statement on what I read in the gcc man page. -ffast-math is used in clang to set fp-contract to fast (default is standard) and in gcc it activates (among others) the flag -funsafe-math-optimizations whose description includes: "Allow optimizations for floating-point

Hi everyone, Sergey (CC’ed) worked on a series of patches to add support for floating-point environment and floating-point rounding modes in LLVM. This started *in 2014* and the patches after multiple rounds of review in the last months (involving amongst other Steve Canon, Hal Finkel, David Majnemer, and myself) are getting very close (IMO) to be in a state where we can land them. This is the

Hello, I want to implement LLVM backend for a specific VLIW hardware. I am working on defining its instruction set, and assembly language. The hardware has two pipelines, int and float. Each pipeline can do 3 operations/cycle, 3 operations forms an instruction. One of the Integer Instruction looks like this: add Ri, Rj, Rk; add Rl, Rm, Rn; add Ro, Rp, Rq An int instruction and a float

Hi Chandler, This scheme has significant advantages over what was being pursued, but one question (or two)... Under the proposed system, how would you represent the necessary dependency edges between the fp intrinsics and function calls? How is the state 'returned' to the caller? [I was thinking that our new operand bundles could help for the inputs, but the outputs? Plus what about the

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, February 5, 2016 4:36:54 PM > Subject: Re: [llvm-dev] [RFC] FP Environment and Rounding mode

FWIW, +1 from me. Just one request on the implementation though. However we model these intrinsics and their properties (metadata, constants, etc), can we please abstract away those details the same way we have MemCpyInst which just wraps an IntrinsicInst? I think this would be very beneficial if we ever need to add more state, or change something about the underlying implementation, and not

I'll give some data points from our OpenVMS Itanium (and Alpha) platforms where we support multiple IEEE modes and dynamic rounding in our C and Fortran compilers (we don't have actual FENV_ACCESS in our C product but you can come close). On the command line, you get to pick IEEE modes with:   /IEEE_MODE         /IEEE_MODE=option         /IEEE_MODE=DENORM_RESULTS (D)      Selects the

About ftrapping-math: I think we should eliminate ftrapping-math, a boolean option, because it overlaps with ffp-exception-behavior, a 3 valued option. Or we can keep it in the clang driver for compatibility, but it should be rewritten by clang driver into ffp-exception-behavior=ignore and ffp-exception-behavior=strict. There are various fields in llvm and/or clang that maintain Boolean

Author: mikechr Repository: /hg/zfs-crypto/gate Revision: 3a473014cdbb72a0ecad997583eaabfe2d32283c Log message: 6345621 FMA topo support for Boston/Seattle Files: create: usr/src/cmd/fm/topo/files/sparc/SUNW,Sun-Fire-V215/Makefile create: usr/src/cmd/fm/topo/files/sparc/SUNW,Sun-Fire-V245/Makefile create: usr/src/cmd/fm/topo/files/sparc/SUNW,Sun-Fire-V245/platform.topo create:

Author: elowe Repository: /hg/zfs-crypto/gate Revision: 9af913595d90ad9ae8878d0b0284e6b1acc55d3c Log message: 6378297 FMA page fault events not being replayed due to changes in page retire Files: update: usr/src/uts/common/vm/page_retire.c

On Feb 8, 2012, at 10:44 AM, James Molloy wrote: > Hi Owen, > > Having looked into this due to Clang failing PlumHall with it recently I can give an opinion... > > I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If

On Feb 8, 2012, at 10:42 AM, Hal Finkel wrote: > In my experience, users of numerical codes expect that the compiler will > use FMA instructions where it can, unless specifically asked to avoid > doing so by the user. Even though this can sometimes produce a different > result (*almost* always a better one), the performance gain is too large > to be ignored by default. I highly

Hi, I am looking for the compiler flags/technique for the following code generations in llvm 1) enable and disable FMA3 and FMA4 instruction generation. 2) Enable and disable the vectorized FMA3 and FMA4 instruction generation. Please suggest. Thanks in advance. Best Regards, soham "The search for truth is more precious than its possession." -------------- next part

You hit send right when I did! > For your example, do you mean that it's grouped like: > (fadd (fadd (fmul a b) (fmul c d)) e) > > How would your pass go about handling these patterns and is that something > that would be too complicated for fast-isel to do on the fly? > > Depends on how they're grouped, but if the formation happens prior to codegen then fast-isel will