From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by sourceware.org (Postfix) with ESMTPS id 49B1338357B0 for ; Tue, 15 Nov 2022 11:18:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 49B1338357B0 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-yb1-xb2a.google.com with SMTP id i131so16617580ybc.9 for ; Tue, 15 Nov 2022 03:18:02 -0800 (PST) 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=NjkF3ZNjCB8cscxZAMzBGiDVoii8dKyfsLsMdrd/YPo=; b=n1v7I8mGh0iZ5EXboRNOM3r3m8/xnJEsnrxjGVn9muiP+2LzTrfRhGLyJgZXZS3dHJ DKiW14acFqz6DlNJCaHp27qh4mUWNrVJ2YlbgM7l/6gB7XprbFAPrKJFhYe95NAYY2RE 1+BPXMr0VUiCCFRnAVuvswJpabkvALZIcv1B9cUVwg90FWX7HElwG11FECbdkYqo2mZz XbV9r4OKAEcEKIP8FLFSSbDzqt3oq91Knx3s32CrX3m5ibYEfo/qZTB2zGlyLZi0N50V uv8fvmHUYTyRcbfnVfVyyn/dntG0PbVAG2XZwYmM7R3ayBCEj4a3JcaVDDqRBGzBBYyk 3M4w== 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=NjkF3ZNjCB8cscxZAMzBGiDVoii8dKyfsLsMdrd/YPo=; b=VlNBf4l2ADv6FOgOqTET2lHXEqlteiZJHVzfW8l6SaXt7BphvWGFsK1E1VkNnKce40 iHE+strwj5Hn66Lmvb/LRl9dH7xfVUUZ1uAuBhlnP13pi9S5j8q1zBlVwgi7LUrqLlIt dZuVeQPYjH2IquWnRrR8PA1rpsrWDg0zEzK555eQLiSjN8He/+TahFI3MmKF8u4k1ugp xdcoOLZ3CSh1XDs8IRFVl1fedUckuuEEQPnXCctKECYmRa4vO7eirPNXE4StmufrCZ2M 0dR78nXKrYB7M8KLqB2gw6wHWZoewdonu4cnxVeDqELs0UtnqM2iGdH076BSanW6zfY5 FugQ== X-Gm-Message-State: ANoB5plrbqo0kM3JUm4ePx9QdGym0LxIlxtdpTLGmDPLXKSQD8EEd1zf EI1jsT2VTHRXb0xcJHWjPhcGd4vckCbiGT3zfmc= X-Google-Smtp-Source: AA0mqf6JP27vLYInW5BMH+GDmFwFwvAU4fSBZTjMs5uNpXfDoi3sWfiXt6jkXMKjnfTyyAzA2A5G5Iulx9oBwZxKD8w= X-Received: by 2002:a25:b109:0:b0:6dd:b9a3:7ad4 with SMTP id g9-20020a25b109000000b006ddb9a37ad4mr16670814ybj.611.1668511081650; Tue, 15 Nov 2022 03:18:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Hongtao Liu Date: Tue, 15 Nov 2022 19:17:50 +0800 Message-ID: Subject: Re: [PATCH][i386]: Update ix86_can_change_mode_class target hook to accept QImode conversions To: Tamar Christina Cc: gcc-patches@gcc.gnu.org, nd@arm.com, hubicka@ucw.cz, ubizjak@gmail.com, kirill.yukhin@gmail.com, hongtao.liu@intel.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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 Fri, Nov 11, 2022 at 10:47 PM Tamar Christina via Gcc-patches wrote: > > Hi All, > > The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is currently > not useful before re-alloc. > > In particular before regalloc optimization passes query the hook using ALL_REGS, > but because of the > > if (MAYBE_FLOAT_CLASS_P (regclass)) > return false; > > The hook returns false for all modes, even integer ones because ALL_REGS > overlaps with floating point regs. > > The vector permute fallback cases used to unconditionally convert vector integer > permutes to vector QImode ones as a fallback plan. This is incorrect and can > result in incorrect code if the target doesn't support this conversion. > > To fix this some more checks were added, however that ended up introducing ICEs > in the i386 backend because e.g. the hook would reject conversions between modes > like V2TImode and V32QImode. > > My understanding is that for x87 we don't want to allow floating point > conversions, but integers are fine. So I have modified the check such that it > also checks the modes, not just the register class groups. > > The second part of the code is needed because now that integer modes aren't > uniformly rejected the i386 backend trigger further optimizations. However the > backend lacks instructions to deal with canonical RTL representations of > certain instructions. for instance the back-end seems to prefer vec_select 0 > instead of subregs. If the canonical form of the lower half of the vector in rtl is subreg instead of vec_select, the x86 backend needs to update the pattern accordingly to avoid diverge. I can reproduce those failures when adding VALID_FP_MODE_P in targetm.can_change_mode_class. > > So to prevent the canonicalization I reject integer modes when the sizes of to > and from don't match and when we would have exited with false previously. > > This fixes all the ICEs and codegen regressions, but perhaps an x86 maintainer > should take a deeper look at this hook implementation. > > Bootstrapped Regtested on x86_64-pc-linux-gnu and no issues. > > Ok for master? > > Thanks, > Tamar > > gcc/ChangeLog: > > * config/i386/i386.cc (ix86_can_change_mode_class): Update the target > hook. > > --- inline copy of patch -- > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc > index c4d0e36e9c0a2256f5dde1f4dc021c0328aa0cba..477dd007ea80272680751b61e35cc3eec79b66c3 100644 > --- a/gcc/config/i386/i386.cc > +++ b/gcc/config/i386/i386.cc > @@ -19682,7 +19682,15 @@ ix86_can_change_mode_class (machine_mode from, machine_mode to, > > /* x87 registers can't do subreg at all, as all values are reformatted > to extended precision. */ > - if (MAYBE_FLOAT_CLASS_P (regclass)) > + if (MAYBE_FLOAT_CLASS_P (regclass) > + && VALID_FP_MODE_P (from) > + && VALID_FP_MODE_P (to)) > + return false; > + > + /* Reject integer modes if the sizes aren't the same. It would have > + normally exited above. */ > + if (MAYBE_FLOAT_CLASS_P (regclass) > + && GET_MODE_SIZE (from) != GET_MODE_SIZE (to)) > return false; > > if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass)) > > > > > -- -- BR, Hongtao