On Wed, Aug 05, 2015 at 02:38:01PM +0100, Richard Biener wrote:
> On Wed, 5 Aug 2015, James Greenhalgh wrote:
>
> > On Wed, Aug 05, 2015 at 12:09:35PM +0100, Richard Biener wrote:
> > > On Wed, 5 Aug 2015, Andrew Pinski wrote:
> > >
> > > > On Wed, Aug 5, 2015 at 3:16 AM, Richard Biener <rguent...@suse.de>
> > > > wrote:
> > > > > On Wed, 5 Aug 2015, Andreas Schwab wrote:
> > > > >
> > > > >> Richard Biener <rguent...@suse.de> writes:
> > > > >>
> > > > >> > * gimple-fold.c (gimple_fold_stmt_to_constant_1): Canonicalize
> > > > >> > bool compares on RHS.
> > > > >> > * match.pd: Add X ==/!= !X is false/true pattern.
> > > > >>
> > > > >> ERROR in VTST/VTSTQ
> > > > >> (/opt/gcc/gcc-20150805/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vtst.c
> > > > >> line 97 in buffer 'expected_signed') at type uint8x8 index 1: got
> > > > >> 0x1 != 0xff (signed input)
> > > > >> FAIL: gcc.target/aarch64/advsimd-intrinsics/vtst.c -O1 execution
> > > > >> test
> > > > >> FAIL: gcc.target/aarch64/simd/int_comparisons_1.c
> > > > >> scan-assembler-times [ \t]cmtst[ \t]+v[0-9]+.[0-9]+[bshd],[
> > > > >> \t]*v[0-9]+.[0-9]+[bshd],[ \t]+v[0-9]+.[0-9]+[bshd] 14
> > > > >> FAIL: gcc.target/aarch64/simd/int_comparisons_1.c
> > > > >> scan-assembler-times [ \t]cmtst[ \t]+d[0-9]+,[ \t]*d[0-9]+,[
> > > > >> \t]+d[0-9]+ 4
> > > > >> FAIL: gcc.target/aarch64/simd/int_comparisons_2.c execution test
> > > > >> FAIL: gcc.target/aarch64/singleton_intrinsics_1.c
> > > > >> scan-assembler-times \\tcmtst\\td[0-9]+, d[0-9]+, d[0-9]+ 2
> > > > >
> > > > > Ick - somebody will have to come up with a reduced testcase for one of
> > > > > this (best an execute fail). Reduced to one failing case so I can
> > > > > investigate with a cross compiler.
> > > > >
> > > > > Eventually smells like a aarch64 vector specific issue or a latent
> > > > > issue with the truth_valued_p predicate for vector types.
> > > >
> > > > Or constant_boolean_node is not returning {-1,-1,-1,-1} for true
> > > > vectors.
> > >
> > > It does.
> >
> > You could try with the attached (execute) testcase.
> >
> > Output for me (x86_64/AArch64 trunk compiler) is:
> >
> > Expected: 0000ffffffffff00 Got: 00007f80807f8000
> >
> > Those folded values look suspicious! We fold as so:
> >
> > arg1_2 = { -128, -1, 127, -122, -128, -1, 0, 118 };
> > arg2_3 = { 127, -128, 127, -128, -1, 127, 127, 0 };
> >
> > Visiting statement:
> > _5 = arg1_2 & arg2_3;
> > which is likely CONSTANT
> > Match-and-simplified arg1_2 & arg2_3 to { 0, -128, 127, -128, -128, 127, 0,
> > 0 }
> > Lattice value changed to CONSTANT { 0, -128, 127, -128, -128, 127, 0, 0 }.
> > Adding SSA edges to worklist.
> > interesting_ssa_edges: adding SSA use in _13 =
> > VIEW_CONVERT_EXPR<uint8x8_t>(_5);
> > marking stmt to be not simulated again
> >
> > I'd have expected masks of "-1" in the true vector lanes rather than what
> > we end up with.
>
> __extension__ static __inline uint8x8_t __attribute__
> ((__always_inline__))
> vtst_s8 (int8x8_t __a, int8x8_t __b)
> {
> return (uint8x8_t) ((__a & __b) != 0);
> }
>
> you expect that to be a truth and but it is a bitwise and. So IMHO
> it works "as expected". Does the backend actually generate a truth-and
> instruction for vtst_s8!?
Sorry, I pasted an unhelpful part of the log...
I'd have expected the "!= 0" to give a truth value, but we've already lost
that after early inline:
arg1_2 = { -128, -1, 127, -122, -128, -1, 0, 118 };
arg2_3 = { 127, -128, 127, -128, -1, 127, 127, 0 };
_5 = arg1_2 & arg2_3;
_13 = VIEW_CONVERT_EXPR<uint8x8_tD.2339>(_5);
_14 = _13;
result_6 = _14;
_7 = VIEW_CONVERT_EXPR<vector(1) long unsigned intD.10>(result_6);
_8 = _7;
got_9 = BIT_FIELD_REF <_8, 64, 0>;
After which,
_5 = arg1_2 & arg2_3;
folds to non-truth values as expected (as you say, that is a bitwise and) but
we've dropped the "!= 0" which was in vtst_s8 and that we were relying on
to get our truth value masks out.
vtst_s8 (int8x8_tD.2338 __aD.2341, int8x8_tD.2338 __bD.2342)
{
vector(8) signed charD.17 _3;
vector(8) signed charD.17 _4;
uint8x8_tD.2339 _5;
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;; prev block 0, next block 1, flags: (NEW, REACHABLE)
;; pred: ENTRY (FALLTHRU)
_3 = __a_1(D) & __b_2(D);
_4 = _3 != { 0, 0, 0, 0, 0, 0, 0, 0 };
_5 = VIEW_CONVERT_EXPR<uint8x8_tD.2339>(_4);
# VUSE <.MEM_6(D)>
return _5;
;; succ: EXIT
}
Sorry for the poor communication.
James
>
> Anyway, trying a cross now.
>
> > Thanks,
> > James
> >
> >
>
> --
> Richard Biener <rguent...@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham
> Norton, HRB 21284 (AG Nuernberg)
>
