diff mbox

[testsuite] Skip gcc.dg/ifcvt-4.c for targets on which it may not work

Message ID 20151218095459.GA18260@arm.com
State New
Headers show

Commit Message

James Greenhalgh Dec. 18, 2015, 9:55 a.m. UTC
This is a multi-part message in MIME format.
--------------2.2.0.1.gd394abb.dirty
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Hi,

PR68232 is a testsuite failure for targets with very low branch costs.
As the test is looking for if-conversion, it will fail for any subtarget
for which the cost of a branch is sufficiently low that if-conversion looks
more expensive.

In the current implementation this will be any subtarget with an unpredictable
 branch cost of 0 or 1. I had thought this would be very few targets, but
at least powerpc64le and arm can trigger this for particular tuning targets.

This patch skips the test on those targets.

OK?

Thanks,
James

---
2015-12-17  James Greenhalgh  <james.greenhalgh@arm.com>

	PR testsuite/68232
	* gcc.dg/ifcvt-4.c: Skip for arm*-*-* and powerpc64le*-*-*.


--------------2.2.0.1.gd394abb.dirty
Content-Type: text/x-patch; name="0001-Patch-testsuite-Skip-gcc.dg-ifcvt-4.c-for-targets-on.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Patch-testsuite-Skip-gcc.dg-ifcvt-4.c-for-targets-on.patch"


--------------2.2.0.1.gd394abb.dirty--

Comments

Jeff Law Dec. 21, 2015, 7:38 p.m. UTC | #1
On 12/18/2015 02:55 AM, James Greenhalgh wrote:
> This is a multi-part message in MIME format.
> --------------2.2.0.1.gd394abb.dirty
> Content-Type: text/plain; charset=UTF-8; format=fixed
> Content-Transfer-Encoding: 8bit
>
>
> Hi,
>
> PR68232 is a testsuite failure for targets with very low branch costs.
> As the test is looking for if-conversion, it will fail for any subtarget
> for which the cost of a branch is sufficiently low that if-conversion looks
> more expensive.
>
> In the current implementation this will be any subtarget with an unpredictable
>   branch cost of 0 or 1. I had thought this would be very few targets, but
> at least powerpc64le and arm can trigger this for particular tuning targets.
>
> This patch skips the test on those targets.
>
> OK?
>
> Thanks,
> James
>
> ---
> 2015-12-17  James Greenhalgh  <james.greenhalgh@arm.com>
>
> 	PR testsuite/68232
> 	* gcc.dg/ifcvt-4.c: Skip for arm*-*-* and powerpc64le*-*-*.
OK.

FWIW, I'd really like to see someone cleanly tweak config-list.mk so 
that we can use it to test this kind of stuff.

In theory what I want to be able to do is build all the listed targets 
and run a single test on them so that we can build these skip/xfail 
lists much easier.

I've done it a few times by hand and it seems like it's something we 
ought to be able to do much more easily.

Jeff
Richard Earnshaw (lists) Dec. 22, 2015, 11:24 a.m. UTC | #2
On 21/12/15 19:38, Jeff Law wrote:
> On 12/18/2015 02:55 AM, James Greenhalgh wrote:
>> This is a multi-part message in MIME format.
>> --------------2.2.0.1.gd394abb.dirty
>> Content-Type: text/plain; charset=UTF-8; format=fixed
>> Content-Transfer-Encoding: 8bit
>>
>>
>> Hi,
>>
>> PR68232 is a testsuite failure for targets with very low branch costs.
>> As the test is looking for if-conversion, it will fail for any subtarget
>> for which the cost of a branch is sufficiently low that if-conversion
>> looks
>> more expensive.
>>
>> In the current implementation this will be any subtarget with an
>> unpredictable
>>   branch cost of 0 or 1. I had thought this would be very few targets,
>> but
>> at least powerpc64le and arm can trigger this for particular tuning
>> targets.
>>
>> This patch skips the test on those targets.
>>
>> OK?
>>
>> Thanks,
>> James
>>
>> ---
>> 2015-12-17  James Greenhalgh  <james.greenhalgh@arm.com>
>>
>>     PR testsuite/68232
>>     * gcc.dg/ifcvt-4.c: Skip for arm*-*-* and powerpc64le*-*-*.
> OK.
> 
> FWIW, I'd really like to see someone cleanly tweak config-list.mk so
> that we can use it to test this kind of stuff.
> 
> In theory what I want to be able to do is build all the listed targets
> and run a single test on them so that we can build these skip/xfail
> lists much easier.
> 
> I've done it a few times by hand and it seems like it's something we
> ought to be able to do much more easily.
> 
> Jeff
> 

The bigger problem here is that branch costs are a property of a
specific CPU, not the target architecture.  So deciding whether or not
we should skip this test (and perhaps others like it) is impossible
given that we can't know what the default CPU for the compiler is (and
even if we did know, maintaining such a list would be almost impossible).

R.
Jeff Law Dec. 22, 2015, 7:12 p.m. UTC | #3
On 12/22/2015 04:24 AM, Richard Earnshaw (lists) wrote:

>
> The bigger problem here is that branch costs are a property of a
> specific CPU, not the target architecture.  So deciding whether or not
> we should skip this test (and perhaps others like it) is impossible
> given that we can't know what the default CPU for the compiler is (and
> even if we did know, maintaining such a list would be almost impossible).
True, but you still get a reasonable set of targets where the test 
passes vs fails -- not all the targets have as many variants as ARM :-)

I'd certainly agree that covering all the subtargets and then keeping 
those lists accurate sounds like a lot of make-work.


jeff
Mike Stump Dec. 24, 2015, 7:39 p.m. UTC | #4
On Dec 22, 2015, at 3:24 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
>> In theory what I want to be able to do is build all the listed targets
>> and run a single test on them so that we can build these skip/xfail
>> lists much easier.
>> 
>> I've done it a few times by hand and it seems like it's something we
>> ought to be able to do much more easily.

> The bigger problem here is that branch costs are a property of a
> specific CPU, not the target architecture.  So deciding whether or not
> we should skip this test (and perhaps others like it) is impossible
> given that we can't know what the default CPU for the compiler is (and
> even if we did know, maintaining such a list would be almost impossible).

As I see it, I don’t see any prohibition that c2e-gcc --target not list the information you seek.  Nor do I see any prohibition that dejagnu not run the compiler with the that flag, nor that it read it and understand how gcc was configured.  Neither do I see a prohibition that dejagnu not run a target piece of code to dynamically determine on what type of cpu (or/system) the code is running on.  So, any desire not to do this, I think is a decision for the port maintainer alone.  If they want to do this, they can, it they want to not do this, that’s their prerogative.  Further, a port is free to have built-in preprocessor symbols that describe the targeted cpu and/or architecture.

One can even imagine that gcc provides feature test macros that can be used to make tests more portable. 

As for what’s best, that’s for port maintainers and backend maintainers to decide.  :-)
diff mbox

Patch

diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 16be2b0..e1c81fb 100644
--- a/gcc/testsuite/gcc.dg/ifcvt-4.c
+++ b/gcc/testsuite/gcc.dg/ifcvt-4.c
@@ -1,4 +1,6 @@ 
 /* { dg-options "-fdump-rtl-ce1 -O2" } */
+/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" { "arm*-*-* powerpc64le*-*-*" } {"*"} { "" } }  */
+
 int
 foo (int x, int y, int a)
 {