From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73234 invoked by alias); 17 Jul 2018 17:42:12 -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 72338 invoked by uid 89); 17 Jul 2018 17:42:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=scientific, emits, H*f:sk:9d0cf3d, benchmarked X-HELO: cc-smtpout2.netcologne.de Received: from cc-smtpout2.netcologne.de (HELO cc-smtpout2.netcologne.de) (89.1.8.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 17:42:09 +0000 Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id 56B86127EC; Tue, 17 Jul 2018 19:42:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1531849327; bh=wLRWNMse/CpnLxtcqN7WHdyRHBnK1upgHijqvipuAQ4=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To:From; b=MJEN7JkAHQGMCrxy2HxFnc/8mmZprZ7dT45MMTdhak6QIhz/8KKa4BngMUJjxyCYL GHlfl7Ho2X9IuwKvRO6rONq5z/6OmfRH3Hai1vJggGjdextRWYhje4TAw480h9NfvW s8zzKLd6P3wHOb+wZILKB/2kVKSSIUAgSGWbArejkJZBAelVRPaBz8AuMPlabN9Ysf AXaVmzz9n9mp7Hn4GDXGGlfm29bBZOC3SaLvMWmr9vjkDeWVN2DQvqx8wArsbDTk1A BRcz3JSM1BmSXe3khQvvwWwU9PGvEwwSLZ6sdB6OXGJaKanF5KLaXbmZ0q6a39K/ZE 0wVxkUWGATP5A== Received: from localhost (localhost [127.0.0.1]) by cc-smtpin3.netcologne.de (Postfix) with ESMTP id 5162111EAF; Tue, 17 Jul 2018 19:42:07 +0200 (CEST) Received: from [78.35.156.152] (helo=cc-smtpin3.netcologne.de) by localhost with ESMTP (eXpurgate 4.6.0) (envelope-from ) id 5b4e2a6f-0bea-7f0000012729-7f000001a1d8-1 for ; Tue, 17 Jul 2018 19:42:07 +0200 Received: from [192.168.178.68] (xdsl-78-35-156-152.netcologne.de [78.35.156.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA; Tue, 17 Jul 2018 19:42:03 +0200 (CEST) Subject: Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate To: Kyrill Tkachov , Richard Biener Cc: "fortran@gcc.gnu.org" , GCC Patches References: <5B4DE283.9060100@foss.arm.com> <5B4DF325.2050609@foss.arm.com> <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> <5B4E1654.3010806@foss.arm.com> From: Thomas Koenig Message-ID: <2de55fd6-f6e8-ccb1-e684-dc7333e7f49e@netcologne.de> Date: Tue, 17 Jul 2018 17:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <5B4E1654.3010806@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00951.txt.bz2 Hi Kyrill, > Because the expansion now emits straightline code rather than > conditionals and branches > it should be easier to optimise in general, so I'd expect this to be an > improvement overall. > That said, I have benchmarked it on SPEC2017 on aarch64. > If you have any benchmarks of interest to you you (or somebody else) can > run on a target that you > care about I would be very grateful for any results. Well, most people currently use x86_64 for scientific computing, so I would be concerned most about this architecture. As for the test case, min / max performance clearly has an effect on 521.wrf, so this would be ideal. If you could run 521.wrf on x86_64, and find that it does not regress measureably (or even shows an improvement), the patch is OK. I'd be interested in the timings you get. Regards Thomas