From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57558 invoked by alias); 20 Sep 2016 14:42:28 -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 57546 invoked by uid 89); 20 Sep 2016 14:42:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=opportunity, living 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 Sep 2016 14:42:22 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 627747EA87; Tue, 20 Sep 2016 14:42:21 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-2.phx2.redhat.com [10.3.116.2]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8KEgKUj021935; Tue, 20 Sep 2016 10:42:21 -0400 Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible To: Tamar Christina , GCC Patches , "jakub@redhat.com" , "rguenther@suse.de" References: <6c97e2e2-7934-00e3-a4ea-ec94a8c26abc@redhat.com> Cc: nd From: Jeff Law Message-ID: Date: Tue, 20 Sep 2016 14:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01309.txt.bz2 On 09/20/2016 06:00 AM, Tamar Christina wrote: > > > On 16/09/16 20:49, Jeff Law wrote: >> On 09/12/2016 10:19 AM, Tamar Christina wrote: >>> Hi All, >>> + >>> + /* Re-interpret the float as an unsigned integer type >>> + with equal precision. */ >>> + int_arg_type = build_nonstandard_integer_type (TYPE_PRECISION >>> (type), 0); >>> + int_arg = fold_build1_loc (loc, INDIRECT_REF, int_arg_type, >>> + fold_build1_loc (loc, NOP_EXPR, >>> + build_pointer_type (int_arg_type), >>> + fold_build1_loc (loc, ADDR_EXPR, >>> + build_pointer_type (type), arg))); >> Doesn't this make ARG addressable? Which in turn means ARG won't be >> exposed to the gimple/ssa optimizers. Or is it the case that when >> fpclassify is used its argument is already in memory (and thus >> addressable?) >> > I believe that it is the case that when fpclassify is use the argument > is already addressable, but I am not 100% certain. I may be able to do > this differently so I'll come back to you on this one. The more I think about it, the more I suspect ARG is only going to already be marked as addressable if it has already had its address taken. But I think we can look at this as an opportunity. If ARG is already addressable, then it's most likely going to be living in memory (there are exceptions). If ARG is most likely going to be living in memory, then we clearly want to use your fast integer path, regardless of the target. If ARG is not addressable, then it's not as clear as the object is likely going to be assigned into an FP register. Integer operations on the an FP register likely will force a sequence where we dump the register into memory, load from memory into a GPR, then bit test on the GPR. That gets very expensive on some architectures. Could we defer lowering in the case where the object is not addressable until gimple->rtl expansion time? That's the best time to introduce target dependencies into the code we generate. Jeff