From patchwork Wed Sep 25 15:33:50 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 277901 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 664EA2C00CC for ; Thu, 26 Sep 2013 01:34:03 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=rDNkWAZofAeljeOtiyDG8RXo5p4RT9HeqdBUEchukiVcvM 7yQcB6jwc/gL+wX9FKu9n+VasMTDNIxqQHVvdzutlmfgqUOt3PrUs3NDibWDvrRm zZ1KKj+HtN0CPMElcBiekbm9p5Q3YQ6TLJ7s4zwYGfkOf4iqk/9fKZ0z5evjc= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=z4t2O9U4tSoICGDjB2ydRe2moyo=; b=tC35EcYwoXNcTTCp1PS6 vtGA1aeuQBDROMpdaCIHCSP+61DARA7fL4EwzfYm27F2NMtnTzz+tA9Lfyrgq1EY yBERwJXPbAEDZU0+2oWwj/95SjmTrX9KVG6NKVvNbOqPDGCUcg9g3WM8XONSgNdt DN9A0WBvQAY4/9PFSj7zU7w= Received: (qmail 30905 invoked by alias); 25 Sep 2013 15:33:56 -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 30889 invoked by uid 89); 25 Sep 2013 15:33:55 -0000 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; Wed, 25 Sep 2013 15:33:55 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8PFXoZR000988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Sep 2013 11:33:51 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-182.phx2.redhat.com [10.3.113.182]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8PFXogE014291 for ; Wed, 25 Sep 2013 11:33:50 -0400 Message-ID: <5243025E.8050101@redhat.com> Date: Wed, 25 Sep 2013 09:33:50 -0600 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: gcc-patches Subject: [PATCH] Trivial cleanup X-IsSubscribed: yes I was looking at the vec class to figure out the best way to do some things and realized we have a "last" member function. Using foo.last() is clearer than foo[foo.length() - 1] On a related note, our current standards require a space between a function name and the open paren for its argument list. However, it leads to fugly code in some cases. Assume foo is an vec instance and we want to look at something in the last vector element. Our current standards would imply something like this: foo.last ()->bar Which is how the current patch formats that code. However, I typically see this more often in C++ codebases as foo.last()->bar But then, what if we just want the last element without peeking deeper inside it? foo.last ()? or foo.last()? Do we want to make any changes in our style guidelines to handle this better? Anyway, bootstrapped & regression tested on x86_64-unknown-linux-gnu. Installed onto the trunk. Jeff * tree-ssa-threadedge.c (thread_across_edge): Use foo.last () rather than foo[foo.length () - 1] to access last member in a vec. * tree-ssa-threadupdate.c (register_jump_thread): Similarly. diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c index 47db280..2ca56342 100644 --- a/gcc/tree-ssa-threadedge.c +++ b/gcc/tree-ssa-threadedge.c @@ -947,8 +947,7 @@ thread_across_edge (gimple dummy_cond, } remove_temporary_equivalences (stack); - propagate_threaded_block_debug_into (path[path.length () - 1]->dest, - e->dest); + propagate_threaded_block_debug_into (path.last ()->dest, e->dest); register_jump_thread (path, false); path.release (); return; @@ -987,7 +986,7 @@ thread_across_edge (gimple dummy_cond, path.safe_push (taken_edge); found = false; if ((e->flags & EDGE_DFS_BACK) == 0 - || ! cond_arg_set_in_bb (path[path.length () - 1], e->dest)) + || ! cond_arg_set_in_bb (path.last (), e->dest)) found = thread_around_empty_blocks (taken_edge, dummy_cond, handle_dominating_asserts, @@ -999,7 +998,7 @@ thread_across_edge (gimple dummy_cond, record the jump threading opportunity. */ if (found) { - propagate_threaded_block_debug_into (path[path.length () - 1]->dest, + propagate_threaded_block_debug_into (path.last ()->dest, taken_edge->dest); register_jump_thread (path, true); } diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c index 4131128..fd5234c 100644 --- a/gcc/tree-ssa-threadupdate.c +++ b/gcc/tree-ssa-threadupdate.c @@ -1401,7 +1401,7 @@ register_jump_thread (vec path, bool through_joiner) if (!through_joiner) e3 = NULL; else - e3 = path[path.length () - 1]; + e3 = path.last (); /* This can occur if we're jumping to a constant address or or something similar. Just get out now. */