From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87173 invoked by alias); 20 Dec 2016 10:33:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 87157 invoked by uid 89); 20 Dec 2016 10:33:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*MI:sk:2016122, sk:s390_ch, tcl, *.exp X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Dec 2016 10:33:07 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6A6268F268; Tue, 20 Dec 2016 10:33:06 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-54.ams2.redhat.com [10.36.116.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBKAX3V6017202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Dec 2016 05:33:05 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uBKAX1Vv005417; Tue, 20 Dec 2016 11:33:02 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uBKAWwrk005416; Tue, 20 Dec 2016 11:32:58 +0100 Date: Tue, 20 Dec 2016 10:38:00 -0000 From: Jakub Jelinek To: vogt@linux.vnet.ibm.com, gcc-patches@gcc.gnu.org, Andreas Krebbel Subject: Re: [PATCH v2] Run tests only if the machine supports the instruction set. Message-ID: <20161220103258.GF21933@tucnak> Reply-To: Jakub Jelinek References: <20161219142806.GA23636@linux.vnet.ibm.com> <20161219165040.GA15966@linux.vnet.ibm.com> <20161219170021.GW21933@tucnak> <20161220102247.GA5075@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220102247.GA5075@linux.vnet.ibm.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg01694.txt.bz2 On Tue, Dec 20, 2016 at 11:22:47AM +0100, Dominik Vogt wrote: > On Mon, Dec 19, 2016 at 06:00:21PM +0100, Jakub Jelinek wrote: > > On Mon, Dec 19, 2016 at 05:50:40PM +0100, Dominik Vogt wrote: > > > * config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define > > > __S390_ARCH_LEVEL__. > > > gcc/testsuite/ChangeLog-setmem > > > > > > * gcc.target/s390/md/setmem_long-1.c: Use "runnable". > > > * gcc.target/s390/md/rXsbg_mode_sXl.c: Likewise. > > > * gcc.target/s390/md/andc-splitter-1.c: Likewise. > > > * gcc.target/s390/md/andc-splitter-2.c: Likewise. > > > * lib/gcc-dg.exp (gcc-dg-runtest): Export torture_current_flags. > > > * gcc.target/s390/s390.exp: Import torture_current_flags. > > > (check_effective_target_runnable): New. > > > > Unless you want to add support for all targets in the runnable > > effective target, I think it would be better to call it less generically, > > s390_runnable or similar. > > Fair enough. > > What do you think about the change in gcc-dg.exp? > > We couldn't > decide whether it's a valid way of retrieving the flags needed for > compiling s390_check_runnable or not. It would be nice to get all > options that are relevant for the test case, including the ones > from "dg-options" (etc.), but that probably requires larger > changes to lib/*.exp. (The target specific check functions could > be removed then.) I'm not a testsuite maintainer nor very good in tcl, so I think you want a testsuite maintainer to ack it in any case. But, I'd say you want something that will not be terribly expensive. If you have an effective target that happens to get flags from the current test, then that is necessarily non-cacheable, which would mean in addition to compiling every test you also compile another proglet for it. I think your current patch does that too, there is no caching, so it would be desirable to cache the results; you should invalidate those caches when torture_current_flags change. See e.g. et_cache uses in target-supports.exp. You want to remember torture_current_flags for which you've computed the s390_runnable et and if it changes, reset the cache. The other *_runnable flags can be probably just normally cached (and you do, by using check_runtime rather than check_runtime_nocache). Jakub