From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 002E0385701A for ; Thu, 6 Apr 2023 14:46:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 002E0385701A 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-pj1-x102b.google.com with SMTP id j13so37448635pjd.1 for ; Thu, 06 Apr 2023 07:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680792362; x=1683384362; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7RWWVE5nZSNi1euWUTaI5sDJK7K9Fx3o40eJLn9/hoc=; b=bjD91DSs52AK33ZVQbXhokzUKHKlNdoFPuI7tJ+thSzK0eqa6wP4Zg8lhD4ZAVkYd6 VzIZo2S98oDSLNZj5bHeJb6mULazLhN3LiMcxSD1MJsUNBesxUMgmrPCGW57r9mNjp1u FBmVhnPFqjg1KZfnR88uQ4A7ZJI0ldr4yBpDA2YpAxG8eiohAfKC+2eote3eD5kGeX1H MkIBPKnRg1d6bajlvTCu32z9gHE4G8v5/SrtseKoqlVvF0l896uTd3hlj+c8SuhaYoHZ PQa9C3ixh4bECI63EpzxyY6N0SrmKh4Zlh4T5U5ojf8B4Gjnc8VlhgMPQDWN5GGisFCV nxNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680792362; x=1683384362; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7RWWVE5nZSNi1euWUTaI5sDJK7K9Fx3o40eJLn9/hoc=; b=KwmxT10giKFWJ50CkH315Kx5L64Dyat5hidVJriMZgcbTHlA6066O4/RtUFtrKW4/d HgENUqZ5KrKiXKrOdIQwwudLvajOr8Jt7TQw8OyXnZAOajlf0+0f8hQzvVeRJaaNxMBX 0ogtsY1fCxLPoqkt2/4VyutnotvOYXygF0HoZW9vLivxAlPYnGeu8Kwv1iAwMy3KMVmM /u1ZVuWkusqW9vBkFsdCPZ9zv0dBRkp/Fso06UcbL7vgB9Fb7Fg39C/QUGCOjfb/Nost YpOaXpC8tL9/67jeY7Q7D5pPTE/+OkjgkEIBLR6A/Seq2Z3a3CLz7/q4Ry97IWPHJWbg afAA== X-Gm-Message-State: AAQBX9dqfa7OptVfZlJbirSOcapXSQ8lO6X6Hhu58soZ6fJBADhonKYZ yjXphPxkmRMH74fhFUFeY/Y= X-Google-Smtp-Source: AKy350YL6qUb8C/8Uh/kCpmqUorGPD8oc4pLxrdQZyJgPh2v+FQStd7o/Zl/TgG2XJwDKkDX32Oxng== X-Received: by 2002:a17:903:228e:b0:1a1:a727:a802 with SMTP id b14-20020a170903228e00b001a1a727a802mr6695961plh.19.1680792361670; Thu, 06 Apr 2023 07:46:01 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id kf7-20020a17090305c700b001a06b33923bsm1475880plb.164.2023.04.06.07.46.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Apr 2023 07:46:01 -0700 (PDT) Message-ID: <21e6eec0-a49f-954a-5f3e-5a998163bb6b@gmail.com> Date: Thu, 6 Apr 2023 08:45:59 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040] Content-Language: en-US To: Jakub Jelinek , Richard Biener , Eric Botcazou , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: <8e0e3cd5-e4db-ce8a-b7dc-baac32aed516@gmail.com> <612b6215-8bc3-1174-a475-4315176bfe1c@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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,NICE_REPLY_A,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 4/6/23 03:31, Richard Sandiford wrote: > Jeff Law writes: >> On 4/5/23 10:48, Jakub Jelinek wrote: >>> On Wed, Apr 05, 2023 at 10:17:59AM -0600, Jeff Law wrote: >>>>> It is true that an instruction like >>>>> (insn 8 7 9 2 (set (reg:HI 141) >>>>> (subreg:HI (reg:SI 142) 0)) "aauu.c":6:18 181 {*movhi_internal} >>>>> (nil)) >>>>> can appear in the IL on WORD_REGISTER_OPERATIONS target, but I think the >>>>> upper bits shouldn't be random garbage in that case, it should be zero >>>>> extended or sign extended. >>>> Well, that's one of the core questions here. What are the state of the >>>> upper 16 bits of (reg:HI 141)? The WORD_REGISTER_OPERATIONS docs aren't >>>> 100% clear as we're not really doing any operation. >>>> >>>> So again, I think we need to decide if the DSE transformation is correct or >>>> not. I *think* we can aggree that insn 39 is OK. It's really the semantics >>>> of insn 47 that I think we need to agree on. What is the state of the upper >>>> 16 bits of (reg:HI 175) after insn 47? >>> >>> I'm afraid I don't know the answers here, I think Eric is >>> WORD_REGISTER_OPERATIONS expert here I think these days (most of the major >>> targets are !WORD_REGISTER_OPERATIONS). >> Hopefully he'll chime in. > > Just curious: have you experimented with making RISC-V > !WORD_REGISTER_OPERATIONS too? Realise it's not the right way > to fix the bug, just curious in general. We haven't experimented with it AFAIK. We don't have a full set of SImode operations, but we may have enough of a subset to try. Alternately, we could potentially see what happens if we ignore the 32bit ops that we do support. Both general directions are probably worth exploring, but not right now and probably not even for gcc-14 (where we're going to be busy as hell on the vector side). > > Not defining it seems to have worked well for AArch64. And IMO > the semantics are much easier to follow when there is no special > treatment of upper bits. Subregs are hard enough to reason about > as it is... Amen to that. My sense is that the risc-v port relies far too heavily on SUBREGs and the WORD_REGISTER_OPERATIONS just makes reasoning about correctness harder. jeff