This is the mail archive of the
mailing list for the GCC project.
Re: [AArch64] Fix simd intrinsics bug on float vminnm/vmaxnm
- From: Jiong Wang <jiong dot wang at foss dot arm dot com>
- To: Christophe Lyon <christophe dot lyon at linaro dot org>, Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Thu, 7 Jul 2016 10:16:31 +0100
- Subject: Re: [AArch64] Fix simd intrinsics bug on float vminnm/vmaxnm
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20160706152911.GA28331@arm.com> <577D276D.email@example.com> <CAKdteOakjLrKiqy3TTDFgZQFgQHtLxbHCV1zdhYkKR+F=p3mKg@mail.gmail.com>
On 06/07/16 16:55, Christophe Lyon wrote:
I was using dg-xfail-if, (the description is still using "marked as
but later found it's actually broken under advsimd-intrinsics,
On 6 July 2016 at 17:44, Kyrill Tkachov <firstname.lastname@example.org> wrote:
On 06/07/16 16:29, James Greenhalgh wrote:
On Wed, Jul 06, 2016 at 02:11:51PM +0100, Jiong Wang wrote:
The current vmaxnm/vminnm float intrinsics are implemented using
__builtin_aarch64_smax/min<mode> which are mapping to backend patterns
using smin/smax rtl operators. However as documented in rtl.def
"Further, if both operands are zeros, or if either operand is NaN,
it is unspecified which of the two operands is returned as the
There is no guarantee that a number will always be returned through
smin/smax operator, and further tests show gcc will optimize something
like smin (1.0f, Nan) to Nan, so current the vmaxnm and vminnm intrinsics
will evetually fail the new added testcases included in this patch.
* Migrate vminnm/vmaxnm float intrinsics to "<fmaxmin><mode>3" pattern
which guarantee fminnm/fmaxnm sematics.
* Add new testcases for vminnm and vmaxnm intrinsics which were
previously. They are marked as XFAIL on arm*-*-* as ARM hasn't
implemented these intrinsics.
OK for trunk?
The AArch64 parts are OK. I can't remember whether the ARM port prefers
to have missing intrinsics XFAIL'd or if there is another way to disable
the tests that are not supported there. Kyrill/Christophe would you mind
commenting on whether this patch is correct for the intrinsics testsuite?
2016-07-06 Jiong Wang <email@example.com>
* config/aarch64/aarch64-simd-builtins.def (smax): Remove float
(fmax): New entry.
* config/aarch64/arm_neon.h (vmaxnm_f32): Use
These intrinsics are supposed to be available for arm as well *except* for
I missed that point.
So, I agree with Kyrill:
- skip the ones that aren't supposed to be available for arm
- xfail the ones that aren't implemented yet.
given at the same time instead of clean XFAIL, I suspect those dg-do-what
overriding broken dejangu internal variable, Christophe, do you mind
have a look?
Meanwhile, as the new vminnm and vmaxnm testcases are using the existed
infrastructure of vmin/vmax infrastructure which is based on
where only float32 defined. If we enable float64x2, there will be two
* The naming of binary-iop-no64.inc needs to be updated, but it's used by
several other files, so not sure it's the correct approach.
* You will want to xfail only float64x2 testing on ARM inside vmin.c and
vmax.c, I don't know how to do that.
For the vminnm and vmaxnm testing, I really want to go ahead to
for ARM so we won't be bothered by xfail, there is backend pattern
is fmin/fax, however they are standard name without "neon_" prefix,
AArch64, ARM neon builtins infrastructure force the prefix to be
macro expand infrastructure needs to be updated.
For this patch, I am going to change dg-skip-if to dg-xfail-if, but
prepare with those UNRESOLVED failures which will go away once
advsimd-intrinsics.exp fixed. Meanwhile I will create seperate test
float64x2, and dg-skip them on ARM.