From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by sourceware.org (Postfix) with ESMTPS id F14053858C55 for ; Thu, 13 Oct 2022 21:46:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F14053858C55 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3608b5e634aso29903847b3.6 for ; Thu, 13 Oct 2022 14:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gteFM3/dUupFNLSalSAWT5qyi2qDrsGzpWJE5HQrg+U=; b=bcJkDp9W6OgnAzIYgfv31S+SDLvW/V1E2S1AIVzEBxbef1u3wrqx/zLQsYBj5fevlP eRWXmZPgmpaZ6carY0lMq1uKOOof8QcByOJwNr5WwxU0irLnQqbjMaM0eTL+MNKIS6kA Ct1H8byKhKA86eHHByQDCegcwAJvrFzD+u5pQBus86FGytB9RmZm1Dy9eQdzIam9WEYX pzypWSDJRwMFTDgSygkuOZzrF1XvUj6pQb/IKBNkZXks5vTXXZ5hgZHf3PRanbK7gDBl sAXcUtG780qZI7mXJGKUR/Hr8DYoGnwZ4iihueZS+g9dF9d+98qDk8ni6Z0weeohLTRZ WJpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gteFM3/dUupFNLSalSAWT5qyi2qDrsGzpWJE5HQrg+U=; b=Unt3R7KFfdTH6EE64qdXGBu/RZYawgg+YYEgG4DV8fBDlfgyDFzT7N4pouHk8fhsHA iBbSkPYxwD6FyTknX6JunZUxbHbMFDIGaWUCmIZBJL9Tbe0aROCwAriTiF4MlkbNMK4K u1an34KZzVgZzTEKUJE+aMfzWRFPCGvf38dxy25PnSyQATaKA8wa4+XqE9Q4tEUx5Jam z/PUio6p03ALqNleknTfLogW7KQtuJeVuyfmRWz1FkNyGpk2M62f07FOqz7sUsj3kBoc GGe0nf/mtiyiJ9zTbjZCk4ZVWI5Rmxi1iSQXwmZSVIhXHwc5ah3H4qmNWzbbR4bW1U+B zk6Q== X-Gm-Message-State: ACrzQf1LWcfPPH6n4a7DVFAe3nrXItyt4cKFL/3BGHY+BV5UB4bpxGXh uKfYETUwzOq4RFDB8rtUKziBFcNDmueNFWDqDwY= X-Google-Smtp-Source: AMsMyM6tXRG/oBN6+rNtdYiCgAr0uVFoI4pFOsiNEcautsNV+kK/Uveo3meFH/g3KMMgA6DLii2einZzJfCbEJqzW2o= X-Received: by 2002:a81:6f57:0:b0:358:9add:daf3 with SMTP id k84-20020a816f57000000b003589adddaf3mr1965913ywc.422.1665697588240; Thu, 13 Oct 2022 14:46:28 -0700 (PDT) MIME-Version: 1.0 References: <37522634-319a-b471-aa35-87e711b0479e@redhat.com> <55062a15-79a1-f8cf-ed20-25ca8ff42abe@redhat.com> <95f2abba-afb4-bb73-a9f0-b1578b28713a@redhat.com> <5598547f-ce63-6b4d-31e4-a15f57b8f224@redhat.com> In-Reply-To: From: Uros Bizjak Date: Thu, 13 Oct 2022 23:46:17 +0200 Message-ID: Subject: Re: [PATCH] middle-end, c++, i386, libgcc, v2: std::bfloat16_t and __bf16 arithmetic support To: Jakub Jelinek Cc: Jason Merrill , "Joseph S. Myers" , Richard Biener , Jeff Law , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Oct 13, 2022 at 11:35 PM Jakub Jelinek wrote: > > On Thu, Oct 13, 2022 at 11:11:53PM +0200, Uros Bizjak wrote: > > > > + do_compare_rtx_and_jump (op1, op2, GET_CODE (operands[0]), 0, > > > > + SFmode, NULL_RTX, NULL, > > > > + as_a (operands[3]), > > > > + /* Unfortunately this isn't propagated. */ > > > > + profile_probability::even ()); > > > > You could use ix86_expand_branch instead of do_compare_rtx_and_jump > > here. This would expand in SFmode, so insn condition from cbranchsf4 > > should be copied here: > > > > "TARGET_80387 || (SSE_FLOAT_MODE_P (SFmode) && TARGET_SSE_MATH)" > > > > Additionally, ix86_fp_comparison_operator predicate should be used for > > operator0. Basically, just copy predicates from cbranchsf4 as we are > > effectively expanding the SFmode compare & branch. > > The reason why I've used there the generic routine was exactly to handle > not just ix86_fp_comparison_operator, but also comparisons that are more > complex than that (need 2 comparisons). > > While for ix86_fp_comparison_operator cases the optabs wouldn't be actually > strictly needed, the generic code would see e.g. cbranchbf4 isn't supported > and try cbranchsf4, succeed on that and the only disadvantage would be > that the BFmode -> SFmode extensions would be performed using library > functions unless -ffast-math while they can be handled by left shifting > the 16 BFmode bits to most significant 16 bits of SFmode even when honoring > NaNs, for the non-ix86_fp_comparison_operator cases the generic behavior > is actually that neither cbranchbf4, nor cbranchsf4, nor cbranchdf4, nor > cbranchxf4, nor cbranchtf4 works out and generic code emits a libcall > (__{eq,ne}bf2). I bet that is the reason why libgcc contains __{eq,ne}hf2 > entrypoints. > I wanted to avoid adding __{eq,ne}bf2 and the addition of > cbranchbf4/cstorebf4 was how I managed to do that; by telling the > generic code that it can handle those by the faster BFmode to SFmode > conversions of the operands and then perform one or two bit checks. Thanks, for the explanation, I see the intention now. The patch is OK as is. Thanks, Uros. > I guess another possibility would be to call ix86_expand_branch there > once or twice and repeat what the generic code does, or add the > libgcc entrypoints which would perhaps bypass soft-fp and just do the > shifts + SFmode comparison. > > > > > + else > > > > + { > > > > + rtx t2 = gen_reg_rtx (SImode); > > > > + emit_insn (gen_zero_extendhisi2 (t2, op2)); > > > > + emit_insn (gen_ashlsi3 (t2, t2, GEN_INT (16))); > > > > + op2 = gen_lowpart (SFmode, t2); > > > > + } > > > > Similar to cbranch above, use ix86_expand_setcc and copy predicates > > from cstoresf4. > > Ditto here, cstore was actually quite required by the generic code when > cbranch is implemented. > > Jakub >