From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 92991385842F for ; Fri, 14 Oct 2022 16:39:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92991385842F 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-ej1-x630.google.com with SMTP id w18so11656313ejq.11 for ; Fri, 14 Oct 2022 09:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=ZBQDK/YNYt+ZLYz/3H6O4nZClpi8P6/kO1jg/JGA21k=; b=ReTcmfRk0ghNd1GXj8nr/0NvzgfoEoUYFdqgrecuTmuqwHr300bIKIw6LTw0dZpiN2 JykShW5PW3Ws5uoolDB4qZoUyXxivlVRsyNdrxf2EfWslOzkz8v1QMaPj7BNTMsGbnKP 5SoceJxt71YUMBW/Brei3mFoyFFh1dpbfIDadOZ+vVPh7N8JgzULcMGIqxv10QIUGkGW R+ypk06M5QIwgi/QD+Go6HK59JeJCyKTDjTr/dCYwQc/Zlr+FbX0o3i2tovBYfb/TMNr 70VorFUm/IAbQuid7SCDIiVtRKaIROKxNlMY90Ukol8kIN+1F2gNZOc8ZnqJnBfzQi9M Vh0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZBQDK/YNYt+ZLYz/3H6O4nZClpi8P6/kO1jg/JGA21k=; b=smU1RozF8qgAQYjX6RMi3wUZq2fRty+1c6RoSmqnVBkHBOZZMn2vJMJNW1wM8APwln Ti8xVP5ooySQAufwPLTRrlGslnexOWqcGK4YnpUFUWgpHIougHcSuVDP2xqDW6g/B2qk Xo0Gv10F4/Om23FJkST/YQcXlWdW/0MryFo74nrrHrIaXcJvGNMYxLnQWj4bUHdwaTRO 7yJw9X1ujqXeNGBMp8wP9LepA2Vbhb+Qy4KwgKuTYQFzUPMp7jGv0WL7DIejTA2KHHaF 5b8HxLJLEe78w2iqDLCL4UvUnPXTBUAs4Gk19YCIePuO/2DCf43M5RJx1NkdTH6bEkbL iG3A== X-Gm-Message-State: ACrzQf1aq4yCrq56bY3nfXlca1MWABKZO2MpivxtajmNf4oU1G3ZU5K2 b98i+B4uCFuuncYyUhK7JBXOOXy423U= X-Google-Smtp-Source: AMsMyM4FtpP4jQTFhWIhUBl5bncL3wCjvtDT913/kMzLmWXnvI3R7tR0jEVyikKOTNwt66ZZ57leHg== X-Received: by 2002:a17:907:7fa1:b0:782:7c58:5341 with SMTP id qk33-20020a1709077fa100b007827c585341mr4208564ejc.368.1665765567630; Fri, 14 Oct 2022 09:39:27 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-002-029-178.77.2.pool.telefonica.de. [77.2.29.178]) by smtp.gmail.com with ESMTPSA id qn24-20020a170907211800b0073c10031dc9sm1765188ejb.80.2022.10.14.09.39.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 09:39:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] Always enable LRA Date: Fri, 14 Oct 2022 18:39:26 +0200 Message-Id: <5B041D75-19B2-4D8F-906F-CD524ACB5596@gmail.com> References: Cc: "Koning, Paul" , GCC Patches In-Reply-To: To: Jeff Law X-Mailer: iPhone Mail (19H12) X-Spam-Status: No, score=-3.0 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Am 14.10.2022 um 16:40 schrieb Jeff Law via Gcc-patches : >=20 > =EF=BB=BF >> On 10/14/22 06:37, Koning, Paul wrote: >>=20 >>>> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches wrote: >>>=20 >>>=20 >>> On 10/13/22 17:56, Segher Boessenkool wrote: >>>> h8300 fails during GCC build: >>>> /home/segher/src/gcc/libgcc/unwind.inc: In function '_Unwind_SjLj_Raise= Exception': >>>> /home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split in= sn >>>> 141 | } >>>> | ^ >>>> (insn 69 256 327 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [12 S4 A3= 2]) >>>> (reg/f:SI 7 sp)) "/home/segher/src/gcc/libgcc/unwind.inc":118:1= 2 19 {*movsi} >>>> (expr_list:REG_ARGS_SIZE (const_int 4 [0x4]) >>>> (nil))) >>>> during RTL pass: final >>>> which looks like a backend bug, I don't see a pattern that could split >>>> this (without needing an extra clobber)? >>> I'm aware of this -- its invalid RTL: >>>=20 >>> Uses of the register outside of an address are not permitted within the >>> same insn as a use in an embedded side effect expression because such >>> insns behave differently on different machines and hence must be treated= >>> as ambiguous and disallowed. >> I had a bit of a fight with this sort of thing in pdp11, where in fact su= ch operations are executed differently on different machine models. The sol= ution I picked is to create two sets of machine-specific constraint codes, o= ne for "register N" and the other for "autoinc/dec of any register other tha= n N" and pairing those. (You can see this in pdp11.md, the mov defini= tion.) >=20 > I've long suspected the pdp11 was the inspiration for this restriction (I h= ave memories of noting it before I relocated to Utah, so circa 1992). The k= ey problem is the generic parts of the compiler don't know what the semantic= s ought to be -- so it's not obvious when they do a substitution whether or n= ot the substitution of one reg for another is actually valid. It's importan= t to remember that sometimes when we substitute one register for another, we= don't have any contextual information about source vs dest -- it's a long s= tanding wart that causes problems in other cases as well. >=20 > That punts the problem to the backends and the H8 actually tries to deal w= ith this restriction. Basically in the movxx pattern conditions, when the d= estination uses an autoinc addressing mode, the pattern's condition will che= ck that the source register is different. I would expect other ports likely= to do something similar. >=20 > But that approach falls down with reload/lra doing substitutions without v= alidating the result. I guess it might be possible to cobble together somet= hing with secondary reloads, but it's way way way down on my todo list. >=20 > And yes, this case where the autoinc is on the destination works consisten= tly on the H8 as well. We could consider loosening the restrictions and let= this through. It's certainly simpler as it's a doc change and removing a b= it of code on the H8. It sounds like the pdp11 already assumes that case is= valid. But what is the semantics of the RTL IL? That ought to be documented. >=20 > Jeff >=20