From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id C61303858D26 for ; Wed, 22 May 2024 09:28:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C61303858D26 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C61303858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716370141; cv=none; b=Q6eeeze5KYgwWbk1VL4jsWuWTipkMbOmZVjOktSyEBSUlG2Lo5Gf9JCM9jLYhmC4tkJFlYcJnP8SuQemdPn/5dvgovmVsKNGxn/GNxfXs9Ju7zoIIBJ5zJy9iKH8nUReLM6EMqh2KwPZITaXRnIpoHJiDXUzEtsSmPDKdt+WQJo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716370141; c=relaxed/simple; bh=kVKNgb1SsG+YIxp/F4kFv+yi1cYXRDwqAP5g8qLEgrU=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=B/S+/bpMAoZR+Ne3FYKsCZc1u+CZtjNtjLulcxV/pY6nzzOTI9dsWINKcG6h1Tn1YK+HXHaW/ceyDm4miZY6R0AK2X0LT4hBPkUAQkegGMajOADW2I6MFJ+fvgkGYhF5SOLZRsN8oc5QNtE3MVYvKckITuJhDvRFemNX0OfkGSI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6378D339; Wed, 22 May 2024 02:29:23 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE26A3F766; Wed, 22 May 2024 02:28:58 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix mixed input kind permute optimization References: <20240521172620.284CB13685@imap1.dmz-prg2.suse.org> Date: Wed, 22 May 2024 10:28:57 +0100 In-Reply-To: (Richard Sandiford's message of "Tue, 21 May 2024 19:42:09 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-14.4 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Sandiford writes: > Richard Biener writes: >> When change_vec_perm_layout runs into a permute combining two >> nodes where one is invariant and one internal the partition of >> one input can be -1 but the other might not be. The following >> supports this case by simply ignoring inputs with input partiton -1. >> >> I'm not sure this is correct but it avoids ICEing when accessing >> that partitions layout for gcc.target/i386/pr98928.c with the >> change to avoid splitting store dataref groups during SLP discovery. >> >> Bootstrap and regtest running on x86_64-unknown-linux-gnu (ontop of >> the SLP series). The change can't break anything that's already >> broken but I'm not sure this does the right thing - the testcase >> has an uniform constant. I'll try to come up with a better runtime >> testcase tomorrow. Hints as to where to correctly fix such case >> appreciated. > > Famous last words, but yeah, it looks correct to me. I think the > routine in principle should have a free choice of which layout to > choose for invariants (as long as it's consistent for all queries > about the same node). So it should just be a question of whether > keeping the original layout is more likely to give a valid > permutation, or whether going with out_layout_i would be better. > I don't have a strong intuition either way. BTW, I should have said that using a different layout from 0 would require compensating code in the materialize function. So this is definitely the simplest and most direct fix. Thanks, Richard