From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id E813D3858D28 for ; Thu, 29 Sep 2022 07:55:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E813D3858D28 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-ej1-x631.google.com with SMTP id sb3so1078020ejb.9 for ; Thu, 29 Sep 2022 00:55:06 -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; bh=3qxQUkBw5rggUGcKIKqOG0K2UjDNww29AuzC3k0YfXY=; b=Ow/NOU58KQ0AsMzWD6/fFOt3iWoWq6ihae88a4NZewi7hiR+BMJUOYfl44HvggU2OK b0TKs6uRT1JnHbA0QNL4eO9QobR/rO7ndlTMe95kZYIUas+thPY1PjkpU+LtLeekZC06 OZqKChDe1tpqqcEktTtgPTQM35oyoJf6Xdsw9FKQzMx2Lb5gu3r2dwtBPtSnSmqOFHf+ LhubQEKwYHrvF5DWSc414g1f+7caodHfriU7n6fr9qHWx2ygrvNlduSGt8omZ98gZC+Q cNlfaiuRHx2xkefB3DspxlFnRcYVSF0qODd3cqwox2Nd3Ofceau8yuPY21iy1ilgCoUP Ys9g== 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; bh=3qxQUkBw5rggUGcKIKqOG0K2UjDNww29AuzC3k0YfXY=; b=nfXQchupIAPQeRpdcsNCj215dfaOow5/FKfpvRdeFb2pynbZ71pi+OAc1ULpeBezQF fx2DWPHhW3+LmTbu9+J9T0nGYE7D3qLGaJrU7HQw9s43/gl8pAqskpSKEpgFDkVrX3ts YvLjUQ9kQmISwdzZqn6ukTuNSLH1I3hRaCSnNO6pROMZUwlHEJ0hMVCXXFEXuMP34p/W KKncmxmX1ZS7ZfnStiYwhOY79Kr1qCIMlZ/ZvhWCGObiL+EVHw91N8POn4SmxD+b5k71 tfnsNpuxxgQRawaC2zHUFSFji8HqI21xR3l0ls5uI4RCLwgrv2UkIA4U7JPdE/QOxu2L mLEA== X-Gm-Message-State: ACrzQf0DGssGE3EOP+X4PV1FLKpuAXKG9uHDaG9077sNeSSOayN0AOGk 2+Q07vOOyRFfv1IuvoAE1sEb7d0Cel2BKCxqG2JbdPMUttU= X-Google-Smtp-Source: AMsMyM7U3spazJmasF8gN1emil9cfPq4Xore+vyvMd8Pht6lwjoWTBORKCTCzOcs/0zN4EF3KoA1bk8yYkqAewGM8ec= X-Received: by 2002:a17:907:c0e:b0:783:a5c3:eafc with SMTP id ga14-20020a1709070c0e00b00783a5c3eafcmr1694343ejc.29.1664438105752; Thu, 29 Sep 2022 00:55:05 -0700 (PDT) MIME-Version: 1.0 References: <4a6f2350-f070-1473-63a5-3232968d3a89@arm.com> <4ea91767-de43-9d30-5bd2-a9a0759760c7@arm.com> <69abe824-94f5-95b5-fb7f-6fa076973e05@arm.com> <8f805fb1-d4ae-b0e3-ff26-57fd2c1fc1f7@arm.com> <5c3e3af5-c502-fd5a-2792-4e0d1db405ef@arm.com> <42e266bd-7224-76b7-c782-c00063531917@arm.com> <29d958e5-364f-5784-5764-e9b5d364448a@arm.com> In-Reply-To: <29d958e5-364f-5784-5764-e9b5d364448a@arm.com> From: Richard Biener Date: Thu, 29 Sep 2022 09:54:53 +0200 Message-ID: Subject: Re: [PATCH] Teach vectorizer to deal with bitfield accesses (was: [RFC] Teach vectorizer to deal with bitfield reads) To: "Andre Vieira (lists)" Cc: Richard Biener , Jakub Jelinek , Richard Sandiford , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.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 Wed, Sep 28, 2022 at 7:32 PM Andre Vieira (lists) via Gcc-patches wrote: > > Made the change and also created the ChangeLogs. OK if bootstrap / testing succeeds. Thanks, Richard. > gcc/ChangeLog: > > * tree-if-conv.cc (if_convertible_loop_p_1): Move ordering of > loop bb's from here... > (tree_if_conversion): ... to here. Also call bitfield lowering > when appropriate. > (version_loop_for_if_conversion): Adapt to enable loop > versioning when we only need > to lower bitfields. > (ifcvt_split_critical_edges): Relax condition of expected loop > form as this is checked earlier. > (get_bitfield_rep): New function. > (lower_bitfield): Likewise. > (bitfields_to_lower_p): Likewise. > (need_to_lower_bitfields): New global boolean. > (need_to_ifcvt): Likewise. > * tree-vect-data-refs.cc (vect_find_stmt_data_reference): > Improve diagnostic message. > * tree-vect-patterns.cc (vect_recog_temp_ssa_var): Add default > value for last parameter. > (vect_recog_bitfield_ref_pattern): New. > (vect_recog_bit_insert_pattern): New. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/vect-bitfield-read-1.c: New test. > * gcc.dg/vect/vect-bitfield-read-2.c: New test. > * gcc.dg/vect/vect-bitfield-read-3.c: New test. > * gcc.dg/vect/vect-bitfield-read-4.c: New test. > * gcc.dg/vect/vect-bitfield-read-5.c: New test. > * gcc.dg/vect/vect-bitfield-read-6.c: New test. > * gcc.dg/vect/vect-bitfield-write-1.c: New test. > * gcc.dg/vect/vect-bitfield-write-2.c: New test. > * gcc.dg/vect/vect-bitfield-write-3.c: New test. > * gcc.dg/vect/vect-bitfield-write-4.c: New test. > * gcc.dg/vect/vect-bitfield-write-5.c: New test. > > On 28/09/2022 10:43, Andre Vieira (lists) via Gcc-patches wrote: > > > > On 27/09/2022 13:34, Richard Biener wrote: > >> On Mon, 26 Sep 2022, Andre Vieira (lists) wrote: > >> > >>> On 08/09/2022 12:51, Richard Biener wrote: > >>>> I'm curious, why the push to redundant_ssa_names? That could use > >>>> a comment ... > >>> So I purposefully left a #if 0 #else #endif in there so you can see > >>> the two > >>> options. But the reason I used redundant_ssa_names is because ifcvt > >>> seems to > >>> use that as a container for all pairs of (old, new) ssa names to > >>> replace > >>> later. So I just piggy backed on that. I don't know if there's a > >>> specific > >>> reason they do the replacement at the end? Maybe some ordering > >>> issue? Either > >>> way both adding it to redundant_ssa_names or doing the replacement > >>> inline work > >>> for the bitfield lowering (or work in my testing at least). > >> Possibly because we (in the past?) inserted/copied stuff based on > >> predicates generated at analysis time after we decide to elide something > >> so we need to watch for later appearing uses. But who knows ... my mind > >> fails me here. > >> > >> If it works to replace uses immediately please do so. But now > >> I wonder why we need this - the value shouldn't change so you > >> should get away with re-using the existing SSA name for the final value? > > > > Yeah... good point. A quick change and minor testing seems to agree. > > I'm sure I had a good reason to do it initially ;) > > > > I'll run a full-regression on this change to make sure I didn't miss > > anything. > >