From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 127EF3858C39 for ; Fri, 10 Sep 2021 13:58:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 127EF3858C39 Received: by mail-wr1-x42b.google.com with SMTP id w29so2017002wra.8 for ; Fri, 10 Sep 2021 06:58:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=Sctrih+bRN5jiAWRUKJyDgMNUyRoPHst/3AF0yQOAOY=; b=ezF79iixRtJHE3O6yJC6FEl8KboYo/vX87Y2bgQFZPu9obFeIwxihtlPIjOgFdLif4 a2i50EExy/6r6zcktGJgb1lvDogcdpbaWX8UvUrOAN4ZYDkYzHerIvWJ5dbn6U4nxbbS hrHS5REW4Xjl6sC9pWt89NV5lmhbm3gsE7xPeJVxgTggB63Aom05uaAoM1r9eBNc7WP1 H9da/rpr9PmmZkJKzYvxGj3XZEijFb6o6yyYhIlYrOlL/qxaOzEAbBt+DDr+M5uN89HM HOYO3h359uJMS58Gg1V4zw4mOypiV+UvnBP38clyGshigFpqcNE2umL/D2fKKLCo2cEA rpBg== X-Gm-Message-State: AOAM531lpzti66JPyqz+ojAH4AaFoDL+M4P+4yqJ41jbwbBQWd0wvY6T SX6/wFuo/KSeHDziP2cUR8M= X-Google-Smtp-Source: ABdhPJyiwNZ884/OVPx6OR8yLmNL68EWnsBEAZQhNWci5eXTNVfj4FxGUl4NJVggcjL1xxd7EgZ9GQ== X-Received: by 2002:adf:c513:: with SMTP id q19mr9958892wrf.20.1631282329045; Fri, 10 Sep 2021 06:58:49 -0700 (PDT) Received: from [127.0.0.1] (dynamic-077-009-106-008.77.9.pool.telefonica.de. [77.9.106.8]) by smtp.gmail.com with ESMTPSA id j25sm4888678wrc.12.2021.09.10.06.58.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Sep 2021 06:58:48 -0700 (PDT) Date: Fri, 10 Sep 2021 15:58:47 +0200 From: Richard Biener To: Segher Boessenkool CC: liuhongt , GCC Patches , Michael Meissner , Jim Wilson , Andreas Schwab , Andrew Waterman , asolokha@gmx.com Subject: Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE. User-Agent: K-9 Mail for Android In-Reply-To: <20210910133010.GV1583@gate.crashing.org> References: <20210910125818.334531-1-hongtao.liu@intel.com> <20210910125818.334531-3-hongtao.liu@intel.com> <20210910133010.GV1583@gate.crashing.org> Message-ID: <44C6CD6D-B9A5-4ECF-A6DE-6EFC57CD55A6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 13:58:51 -0000 On September 10, 2021 3:30:10 PM GMT+02:00, Segher Boessenkool wrote: >On Fri, Sep 10, 2021 at 03:15:56PM +0200, Richard Biener wrote: >> On Fri, Sep 10, 2021 at 2:58 PM liuhongt wr= ote: >> > if (REG_P (target) >> > - && TRULY_NOOP_TRUNCATION_MODES_P (GET_MODE (target), ext_mo= de)) >>=20 >> ^^^ >>=20 >> I wonder if herein lies the problem in that the HFmode "truncation" fro= m SImode >> is considered noop? Note the underlying target hook only looks at the = mode >> precision and thus receives 16 and 32, and thus maybe that >> TRULY_NOOP_TRUNCATION_MODES_P query only makes sense for >> integer modes? Though the documentation of the hook only talks about >> "conversion" of "values" =2E=2E=2E > >@deftypefn {Target Hook} bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 @= var{outprec}, poly_uint64 @var{inprec}) >This hook returns true if it is safe to ``convert'' a value of >@var{inprec} bits to one of @var{outprec} bits (where @var{outprec} is >smaller than @var{inprec}) by merely operating on it as if it had only >@var{outprec} bits=2E The default returns true unconditionally, which >is correct for most machines=2E When @code{TARGET_TRULY_NOOP_TRUNCATION} >returns false, the machine description should provide a @code{trunc} >optab to specify the RTL that performs the required truncation=2E > > >@cindex @code{trunc@var{m}@var{n}2} instruction pattern >@item @samp{trunc@var{m}@var{n}2} >Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and >store in operand 0 (which has mode @var{n})=2E Both modes must be fixed >point or both floating point=2E > > >TRULY_NOOP_TRUNCATION does not make sense to ask if changing mode class= =2E OK, so there's a mode class comparison missing here which should be a bett= er fix than calling validate_subreg?=20 Richard=2E=20 > >Segher