similar to: [LLVMdev] APFloat renaming isNormal => isFiniteNonZero and isIEEENormal => isNormal

LGTM (and you've already gotten other positive feedback as well). -eric On Tue, Jun 18, 2013 at 3:45 PM, Michael Gottesman <mgottesman at apple.com> wrote: > IEEE-754R defines a normal floating point number as: > > 2.1.38 normal number: For a particular format, a finite non-zero > floating-point number with magnitude greater than or equal to a minimum > bemin value,

I think it’s a splendid idea (but you already knew that). On Jun 18, 2013, at 6:45 PM, Michael Gottesman <mgottesman at apple.com> wrote: > IEEE-754R defines a normal floating point number as: > 2.1.38 normal number: For a particular format, a finite non-zero floating-point number with magnitude greater than or equal to a minimum bemin value, where b is the radix. Normal numbers can

It seems like there is a consensus that this is a good change. Any nay sayers? Michael On Jun 18, 2013, at 5:07 PM, Eric Christopher <echristo at gmail.com> wrote: > LGTM (and you've already gotten other positive feedback as well). > > -eric > > On Tue, Jun 18, 2013 at 3:45 PM, Michael Gottesman <mgottesman at apple.com> wrote: >> IEEE-754R defines a

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0));

Hi, > James, is that a correct assessment? Yes, it is also my belief that the only way ARMv7 NEON differs from IEEE754 is lack of denormal support. James > On 11 Feb 2016, at 10:53, Renato Golin <renato.golin at linaro.org> wrote: > > Hal, > > I had a read on the ARM ARM about VFP and SIMD FP semantics and my > analysis is that NEON's only problem is the

Hi Chandler, > Minor comments: > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return HUGE_VALF; > > Can we add an assert instead of a comment? It's just as documenting and will > catch any goofs. Done. > > + // If it's not a floating point number then it must be 'fast'. > + return

cmake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^

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

On Fri, Mar 25, 2016 at 01:23:03PM +0000, Renato Golin via llvm-dev wrote: > On 25 March 2016 at 04:11, Hal Finkel <hfinkel at anl.gov> wrote: > > As I understand it, the fundamental property being addresses here is: Are > > the semantics of scalar FP math the same as vector FP math? TTI seems like > > a good place to expose that information. If the semantics are indeed

I would like to nominate Nadav Rotem for the x86 backend. Michael On Nov 15, 2012, at 10:51 AM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 15, 2012, at 7:45 AM, "Du Toit, Stefanus" <stefanus.du.toit at intel.com> wrote: > >> I'd like to propose that Michael Liao become the code owner for the x86 backend. >> >> Michael has been

On 3 January 2013 20:53, Michael Gottesman <mgottesman at apple.com> wrote: > All of our internal testers use LNT. LNT behind the scenes just calls the > Makefiles appropriately. So it would be impossible to get rid of the > makefile execution without gutting LNT as well = p. > Hi Michael, The idea was never to gut the makefiles or LNT, but to let all buildbots use LNT to call

On 25 March 2016 at 04:11, Hal Finkel <hfinkel at anl.gov> wrote: > As I understand it, the fundamental property being addresses here is: Are the semantics of scalar FP math the same as vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ...

On Mar 27, 2013, at 6:41 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com> wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto

> It appears that the stats you listed are for movaps [SSE], not vmovaps [AVX]. I would *assume* that vmovaps(m128) is closer to vmovaps(m256), since they are both AVX instructions. Although, yes, I agree that this is not clear from Agner's report. Please correct me if I am misunderstanding. You are misunderstanding [no worries, happens to everyone = )]. The timings I listed were for

This is of course not homework. I am trying to understand how fast math optimizations work in llvm. When I compared IR for both the programs, the only thing I have noticed is that fdiv and fmul are replaced with fdiv fast and fmul fast. Not sure what happens in fdiv fast and fmul fast. I feel that its because d/max is really small number and fast-math does not care about small numbers and consider

On Fri, Jul 27, 2012 at 2:37 PM, Michael Gottesman <mgottesman at apple.com> wrote: ... > I have actually timed said instructions in the past and reproduced Agner > Fog's results. I just prefer to speak by referring to facts that can not be > misconstrued as hearsay = ). That would be great. Also, can you point me to the Agner Fog table that you are referring to? Thanks.

On Nov 15, 2012, at 11:52 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Michael Gottesman" <mgottesman at apple.com> >> To: "Chris Lattner" <clattner at apple.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Thursday, November 15, 2012 12:59:18 PM >> Subject: Re: [LLVMdev] Code ownership

Hi Michael, Can you please cherry pick r195411 into release-3.4 to fix building on older OS X? Thanks, Jeremy commit e323506316cc3948bd801be537a723c308d8e2d4 Author: Michael Gottesman <mgottesman at apple.com> Date: Fri Nov 22 05:00:51 2013 +0000 [block-freq] Update data in test case to be unsigned long long to fix mingw build. git-svn-id:

----- Original Message ----- > From: "Michael Gottesman" <mgottesman at apple.com> > To: "Chris Lattner" <clattner at apple.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, November 15, 2012 12:59:18 PM > Subject: Re: [LLVMdev] Code ownership proposal > > I would like to nominate Nadav Rotem for the x86 backend. Michael has indeed been