From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 2FBDF3858C27 for ; Sat, 11 Sep 2021 08:25:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2FBDF3858C27 Received: by mail-wr1-x429.google.com with SMTP id t18so6157746wrb.0 for ; Sat, 11 Sep 2021 01:25:12 -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=NJ6dpAlJ5Q0E00oSjH6UBJDNBKDEHYDHq5Ci2xxfwB8=; b=FST87/JxmQywbRHKFrzsVRmqCDuVhR9W+R2suS8ZTh2ZmLPQX1CCJyx/BK6bwAVKZs 0WkbFwJgU6Am+Z+a8j9yCIPWDiCdUKdtJEDQ89fOhxkLD7jO9P2HmhM8XKADFMUpupvI ru+J+3ewXc7UZkJlZJ2ABxW73L9ymsYrhU7iumD7+dWaBnWvqlZ1H6LXF6QRvOuhQ/5p Tbl44KNYFhtqlk9wof7B1UhZUoMhOl7sLbWSTQ99ZWuFnrDHHGJkA1KANi+ahrB7EXqt vJxvFVlJ1vkvTRbk8b41JT5RfczGp/Y/rje/15N3oMB19XscLoyqWLN5jlafCe1Vt3sZ WmHA== X-Gm-Message-State: AOAM533wYCWLyoH71ul/fmDdmZvUc9MAygca8UhmE4ox9Wiw0wlYEsI2 VTCaW0OV2IF9zmDAfANiqPo= X-Google-Smtp-Source: ABdhPJyBaQ9mXworJ6ipXcYHB2SluddinO4eZdgkT2m36FCI3/oXfRre+edE/QLrnoJjSQfUPGFKKA== X-Received: by 2002:adf:9f14:: with SMTP id l20mr1941514wrf.427.1631348710816; Sat, 11 Sep 2021 01:25:10 -0700 (PDT) Received: from [127.0.0.1] (dynamic-095-117-032-107.95.117.pool.telefonica.de. [95.117.32.107]) by smtp.gmail.com with ESMTPSA id o26sm972834wmc.17.2021.09.11.01.25.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Sep 2021 01:25:10 -0700 (PDT) Date: Sat, 11 Sep 2021 10:25:08 +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: <20210910212716.GC1583@gate.crashing.org> References: <20210910125818.334531-1-hongtao.liu@intel.com> <20210910125818.334531-3-hongtao.liu@intel.com> <20210910133010.GV1583@gate.crashing.org> <44C6CD6D-B9A5-4ECF-A6DE-6EFC57CD55A6@gmail.com> <20210910162450.GY1583@gate.crashing.org> <20210910212716.GC1583@gate.crashing.org> Message-ID: <82780151-A176-44AE-911E-8FE9D98C2CB4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 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: Sat, 11 Sep 2021 08:25:15 -0000 On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool wrote: >On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: >> On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool wrote: >> >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random t= wo >> >modes: such a truncation needs to have a meaning at all, for the >> >question to make any sense=2E Maybe we can add an assert to this macr= o to >> >root out nonsensical callers? >> > >> >Btw=2E We have >> >#define TRULY_NOOP_TRUNCATION_MODES_P(MODE1, MODE2) \ >> > (targetm=2Etruly_noop_truncation (GET_MODE_PRECISION (MODE1), \ >> > GET_MODE_PRECISION (MODE2))) >> >which is not optimal, either: does truncating DFmode to HFmode behave >> >the same as truncating DImode to HImode, on every target? On *any* >> >target, even?! >>=20 >> When is it for any non-scalar integral mode? I suspect this was only me= aningful for integer modes from the start=2E On x86 i387 math any float mod= e truncation is noop (with not doing actual truncation to inf)=2E=20 > >And trunc on floating point modes was added later? Yeah, sounds like a >good theory=2E > >So we should have an assertion in TNTMP that both modes are integral? >(Scalar of course)=2E No, but in the context we are talking about (bitfield extraction) obviousl= y integer truncate is referred to, a FP truncate doesn't make sense here=2E= So either this piece needs to ask for integer modes and then also pun to t= hem or restrict the operation to integer modes=2E For source int but destin= ation FP there might be other ways to validate whether the target can do th= is, but TNTMP is not it=2E=20 Richard=2E=20 > >Segher