From patchwork Fri Oct 16 12:53:58 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Segher Boessenkool X-Patchwork-Id: 531303 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id B49331402BC for ; Fri, 16 Oct 2015 23:54:12 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=iJEbGfFV; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; q=dns; s=default; b=n4LFsuxofx2x z4Qr/c34IDZxPfanQ9vLqcOaCxYM/y72PbPUski901tv3XaBURrCr/UDy/bYEaOz oNSk3U0/CMrPQ6VsucVwcFaGXuAwmrW/vFn9gQIhGRcdMPcS5J7C66VhV0Yh9BSa gYb1oAV78mq4N9cZg+3wc5H6fNXDTLw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; s=default; bh=ZKUyOhxJLOs1djAB0R TgTUpf2Fc=; b=iJEbGfFVMt8nk1vf3UrxlOw4Ozf7y48l/4fIH0xDCN+FfuSs6i tNixQ2Y/f7DcFodCX8vxfrVma77Ld0ZKZ8pjq1vQKFigzJTlZsK3XMDguMfcktD/ +4i+w4JpccWRU33iqkhZ0colOqlQsY27KqRmdJWcC2i1G6srzakr2PFPA= Received: (qmail 65799 invoked by alias); 16 Oct 2015 12:54:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 65732 invoked by uid 89); 16 Oct 2015 12:54:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: gcc1-power7.osuosl.org Received: from gcc1-power7.osuosl.org (HELO gcc1-power7.osuosl.org) (140.211.15.137) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 16 Oct 2015 12:54:03 +0000 Received: from gcc1-power7.osuosl.org (localhost [127.0.0.1]) by gcc1-power7.osuosl.org (8.15.2/8.15.2) with ESMTP id t9GCs1Cd052501; Fri, 16 Oct 2015 05:54:01 -0700 Received: (from segher@localhost) by gcc1-power7.osuosl.org (8.15.2/8.15.2/Submit) id t9GCs0Zj052500; Fri, 16 Oct 2015 05:54:00 -0700 From: Segher Boessenkool To: gcc-patches@gcc.gnu.org Cc: Segher Boessenkool Subject: [PATCH] mn10300: Use the STC bb-reorder algorithm at -Os Date: Fri, 16 Oct 2015 05:53:58 -0700 Message-Id: <01405f06410764848a190fd41107f24bec9893a0.1444999384.git.segher@kernel.crashing.org> X-IsSubscribed: yes For mn10300, STC still gives better results for optimise-for-size than "simple" does. So use STC at -Os as well. Is this okay for trunk? Segher 2015-10-16 Segher Boessenkool * common/config/mn10300/mn10300-common.c (mn10300_option_optimization_table) : Use REORDER_BLOCKS_ALGORITHM_STC at -Os and up. --- gcc/common/config/mn10300/mn10300-common.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/common/config/mn10300/mn10300-common.c b/gcc/common/config/mn10300/mn10300-common.c index 2df93eb..52421e5 100644 --- a/gcc/common/config/mn10300/mn10300-common.c +++ b/gcc/common/config/mn10300/mn10300-common.c @@ -30,6 +30,9 @@ static const struct default_options mn10300_option_optimization_table[] = { { OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 }, + /* The STC algorithm produces the smallest code at -Os. */ + { OPT_LEVELS_2_PLUS, OPT_freorder_blocks_algorithm_, NULL, + REORDER_BLOCKS_ALGORITHM_STC }, { OPT_LEVELS_NONE, 0, NULL, 0 } };