From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78542 invoked by alias); 16 Aug 2017 11:04:45 -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 69863 invoked by uid 89); 16 Aug 2017 11:04:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2802, story X-HELO: mail-vk0-f45.google.com Received: from mail-vk0-f45.google.com (HELO mail-vk0-f45.google.com) (209.85.213.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Aug 2017 11:04:35 +0000 Received: by mail-vk0-f45.google.com with SMTP id j189so10950562vka.0 for ; Wed, 16 Aug 2017 04:04:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jo3cKivxmyNbAd7+bwE8/NzHF7ffVZJlnaGzx4MdpAo=; b=W1C+rwluJRvODAYPCzLLwCjwBoL8z3eqPKzY8OaJdoHqy4Ojr3Bwx2ViHWhuJ759D0 JHWsubmNF+D1kx9Rrhwzh/SKB6IreRnr5HjZFzlr72aRWCZjyNJequntQpL5VTNma5Xg V3kTUYuTPftx/OLHsF48jwFMB9MiStSb0RtG5/cLiIz4GsF2y5siv6u0JxhCDySqWI09 OYoDsCmdR7Zd4CHK2XnwGecpMPdzqqZmrDMQ+ZUO2Ad3OOczlQSw3RdmBCPnUVNUE8hi T90TVrsj/GXOjfEar7XYRmEAXJLvpF+wVW48/g0YoSro8LGCJU6oVh+P6Nog1JEqo9Hc Lr4g== X-Gm-Message-State: AHYfb5hfD0NuXW1ToQuklymcT3Mptm3oAwfFj28V9cjoAzUAhyJnuuf5 X5IvcALAV3/mv6GfgAO86/JJ85W+3A== X-Received: by 10.31.193.141 with SMTP id r135mr764647vkf.113.1502881474055; Wed, 16 Aug 2017 04:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.218 with HTTP; Wed, 16 Aug 2017 04:04:33 -0700 (PDT) In-Reply-To: References: <20160526175950.GA60285@kam.mff.cuni.cz> <20170815135244.4jsd4jyeg6q2lyjc@virgil.suse.cz> From: Uros Bizjak Date: Wed, 16 Aug 2017 14:01:00 -0000 Message-ID: Subject: Re: Add option for whether ceil etc. can raise "inexact", adjust x86 conditions To: Richard Biener Cc: Joseph Myers , Jan Hubicka , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-08/txt/msg00994.txt.bz2 On Wed, Aug 16, 2017 at 12:55 PM, Richard Biener wrote: > On Wed, Aug 16, 2017 at 12:51 PM, Uros Bizjak wrote: >> On Wed, Aug 16, 2017 at 12:48 PM, Uros Bizjak wrote: >>> On Wed, Aug 16, 2017 at 12:43 PM, Richard Biener >>> wrote: >>>> On Tue, Aug 15, 2017 at 9:21 PM, Uros Bizjak wrote: >>>>> On Tue, Aug 15, 2017 at 4:59 PM, Richard Biener >>>>> wrote: >>>>> >>>>>> So I'd try the "easy" way of expanding if (__builtin_cpu_supports ("sse4.1")) >>>>>> as the sse4.1 sequence is just a single instruction. The interesting part >>>>>> of the story will be to make sure we can emit that even if ! TARGET_ROUND ... >>>>>> >>>>>> Uros, any idea how to accomplish this? Or is the idea of a "local" ifunc >>>>>> better? Note the ABI boundary will be expensive but I guess the conditional >>>>>> sequence as well (and it will disturb RA even if predicted to have SSE 4.1). >>>>> >>>>> TARGET_ROUND is just: >>>>> >>>>> /* SSE4.1 defines round instructions */ >>>>> #define OPTION_MASK_ISA_ROUND OPTION_MASK_ISA_SSE4_1 >>>>> #define TARGET_ISA_ROUND ((ix86_isa_flags & OPTION_MASK_ISA_ROUND) != 0) >>>>> >>>>> I don't remember the history around the #define, once upon a time >>>>> probably made sense, but nowadays it looks that it can be simply >>>>> substituted with TARGET_SSE4_1. >>>> >>>> Sure but we want the backend to use a TARGET_ROUND guarded define_insn >>>> when TARGET_ROUND is false but inside a runtime conditional ensuring that >>>> TARGET_ROUND is satisfied. With doing this with ifuncs we'd mark the function >>>> with a proper target attribute but within a function? >>> >>> How about something intrinsic headers are using? >> >> (... somehow managed to press send too early ...) >> >> There we use GCC_push_options and GCC_target pragmas. Maybe we also >> need corresponding __ROUND__ define defined by the compiler. > > Those don't work inside a function. Remember I want to change the expander > of ceil () to > > if (__builtin_cpu_supports ("sse4.1")) > ceil_for_sse4.1 (); > else > ceil (); > > from the x86 target code that expands ceil for ! TARGET_ROUND. I suppose > we could simply use a separate pattern for SSE 4.1 roundsd here (does it > have to be an unspec? I suppose so to prevent it from being generated by > other means and to prevent code motion out of the conditional?) > > Or forgo with the idea to use inline conditional code and emit an ifunc > dispatcher, a function with the sse4.1 instruction, and a call to the dispatcher > ourselves. Hm ... Maybe in this case an example from libatomic, how cmpxchg16 is handled comes handy. Uros.