Patchwork [testsuite] gcc.dg/vect/vect-50.c: combine two scans

login
register
mail settings
Submitter Janis Johnson
Date June 27, 2012, 10:36 p.m.
Message ID <4FEB8ADF.1000305@mentor.com>
Download mbox | patch
Permalink /patch/167755/
State New
Headers show

Comments

Janis Johnson - June 27, 2012, 10:36 p.m.
These scans from gcc.dg/vect/vect-50.c, and others similar to them in
other vect tests, hurt my brain:

/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align } } } }  */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */

Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the
gcc test summary.  I'm pretty sure the following accomplishes the same
goal:

/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */

That is, run the check everywhere and expect it to fail for effective
targets for which vect_no_align is true and vect_hw_misalign is false.

Tested on i686-pc-linux-gnu and arm-none-eabi.  I'm enough confused that
I'm not going to call this one obvious, it needs a sanity check from
someone else; OK for trunk?

Janis
2012-06-27  Janis Johnson  <janisjo@codesourcery.com>

	* gcc.dg/vect/vect-50.c: Combine two scans.
Mike Stump - June 28, 2012, 12:05 a.m.
On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
> other vect tests, hurt my brain:
> 
> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align } } } }  */
> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */
> 
> Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the
> gcc test summary.  I'm pretty sure the following accomplishes the same
> goal:
> 
> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */

I don't think so?  The first sets the xfail status for the testcase.  If you change the condition, you can't the xfail state for some targets, which would be wrong (without a vec person chiming in).

I'd like to think you can compose the two with some spelling...  I just don't think this one is it.?

I grepped around and found:

  /* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } xfail *-*-* } 8 } */

which might have the right way to spell it, though, I always test to ensure the construct does what I want.

> That is, run the check everywhere

We don't want to run the test on other than vect_hw_misalign targets, right?
Janis Johnson - June 28, 2012, 5:26 p.m.
On 06/27/2012 05:05 PM, Mike Stump wrote:
> On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
>> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
>> other vect tests, hurt my brain:
>>
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align } } } }  */
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */
>>
>> Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the
>> gcc test summary.  I'm pretty sure the following accomplishes the same
>> goal:
>>
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */
> 
> I don't think so?  The first sets the xfail status for the testcase.  If you change the condition, you can't the xfail state for some targets, which would be wrong (without a vec person chiming in).

The two checks are run separately.  The first one runs everywhere and
is expected to fail for vect_no_align.  The second is only run for
vect_hw_misalign.  Targets for which vect_no_align is false and
vect_hw_misliang is true get two PASS reports.

> I'd like to think you can compose the two with some spelling...  I just don't think this one is it.?

No, there is no way to combine "target" and "xfail", although since we
intercept them we could presumably come up with a way to do that, with
syntax and semantics we design.

> I grepped around and found:
> 
>   /* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } xfail *-*-* } 8 } */
> 
> which might have the right way to spell it, though, I always test to ensure the construct does what I want.

Nope.  That should be flagged as an error by dg-message but it's
passed through GCC's process-message which ignore errors (a bug)
and simply ignores the directive.  I'm currently trying a fix to
not ignore errors from dg-error/dg-warning/dg-message and will then
fix up the broken tests.

>> That is, run the check everywhere
> 
> We don't want to run the test on other than vect_hw_misalign targets, right?
> 

I don't know, but right now it's run everywhere at least once.

Janis
Mike Stump - June 29, 2012, 3:02 a.m.
On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote:
> No, there is no way to combine "target" and "xfail",

Ah...  Grrr....  I hate non-composability.  Given that, I think the original patch is fine, subject of course to the wants and wishes of vect people.
Janis Johnson - June 29, 2012, 3:45 p.m.
On 06/28/2012 08:02 PM, Mike Stump wrote:
> On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote:
>> No, there is no way to combine "target" and "xfail",
> 
> Ah...  Grrr....  I hate non-composability.  Given that, I think the original patch is fine, subject of course to the wants and wishes of vect people.

I should have said that *currently* there is no way to combine them.
We override dg-process-target and can come up with a way to provide
both "target" and "xfail" in the target-selector.  Something like:

  target { selector } xfail { selector }

where "target" is the first argument, "xfail" is the third.
Selectors can be lists of target triplets, but those can be within
braces making them a single argument.  What do you think?

Janis
Mike Stump - June 29, 2012, 6:09 p.m.
On Jun 29, 2012, at 8:45 AM, Janis Johnson wrote:
> Something like:
> 
>  target { selector } xfail { selector }
> 
> where "target" is the first argument, "xfail" is the third.

Forcing (requiring) an ordering would be bad.

> Selectors can be lists of target triplets, but those can be within
> braces making them a single argument.  What do you think?

I love composability.  The exact syntax I think falls out from the implementation...  I'd leave that to the implementor.

Patch

Index: gcc.dg/vect/vect-50.c
===================================================================
--- gcc.dg/vect/vect-50.c	(revision 189025)
+++ gcc.dg/vect/vect-50.c	(working copy)
@@ -61,8 +61,7 @@ 
    align the store will not force the two loads to be aligned).  */
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align } } } }  */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { target vect_hw_misalign } } } */
+/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail { vect_no_align && {! vect_hw_misalign } } } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { xfail { vect_no_align || {! vector_alignment_reachable} } } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using versioning." 3 "vect" { target vect_no_align } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using versioning." 1 "vect" { target { {! vector_alignment_reachable} && { {! vect_no_align } && {! vect_hw_misalign } } } } } } */