From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 7F8543858D38 for ; Fri, 14 Oct 2022 17:11:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7F8543858D38 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-x102e.google.com with SMTP id d7-20020a17090a2a4700b0020d268b1f02so8484309pjg.1 for ; Fri, 14 Oct 2022 10:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rnucq8PbtEBqu2XiFUPJ0ZXeaWDnF6CWhcFV7/e7R10=; b=ico1XxCwr9kl/ozJXKLjfOpJpwyGi51aMbceUl1LrBmy/9HonsC4h0l5RaPfsL2l4d EvrEVWjV/RnyDSShMk4H9VMRFHl/+fSdF5EpOpovW5p4wdK+FZqGgN432FsVZFZrxs8w gJpD5nRYbTRiNklnKL2NE5rzDEgHvxd1hrE8y2emSQh0SgKqmaBb3UatVa/Vdkzxz799 g/lnYo6om0jR2xhD95dFCbumMFbWKt+NWsL+Mwtp1pJUT8rLume8CPRaev/7FhzANUFQ E2KaJM7PvxSm/WBrFG2c6kkOQxsYgRytoI13XbR4TWNXUWPhgNf2D7/VX1+ONrct6W4w bCgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc: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=rnucq8PbtEBqu2XiFUPJ0ZXeaWDnF6CWhcFV7/e7R10=; b=4O75S97Swl3upv/hp8DtGbmNe1wGPuXyxFSRQgpWICUw7PZh2V4AZFiSkt6kXRwhp9 3Y7a7rGmJ/VrT8HOb7BNNPKX/BFE7f+ZPzGJe3wJxspK38Dm+4rFz5ItnrHg87Ux5B08 aC5KlY5rqlY2sjIv8mKEzg7gX/Qp1O4ULeMKSvABiWpWSEHGm9yRQDnPyFq9EJvaaAav PeQ9V1ZelDl1eLSz2PYS2e0mCf/0QOmqYR0Tdb58K3XdjAtZdLPX71tT4XfZpCkyWfK2 gsGjd1GwAPsvxUUAZtOLMLTIN8M7Fk3RxyTFcfxOWhjQpRcuKsLOylxmgL/x7LH16Log EVYQ== X-Gm-Message-State: ACrzQf03j+k+rwmtMv5rTn5aX5rIci37SkNpYKANNZhEb4Lrggxn4Za8 5pxrU0ImhUt1yHh5k0+gwaE= X-Google-Smtp-Source: AMsMyM4JkktA5Uerp80HBDUUJd6Jtqs0rVUcQmGC08OLltQ5DtdMzN8VuUZNF10ksSqCkpaZH/yLCg== X-Received: by 2002:a17:90b:4d0d:b0:20d:6fc0:51 with SMTP id mw13-20020a17090b4d0d00b0020d6fc00051mr12179871pjb.10.1665767488328; Fri, 14 Oct 2022 10:11:28 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id l8-20020a170903120800b0016f8e8032c4sm2002708plh.129.2022.10.14.10.11.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 10:11:27 -0700 (PDT) Message-ID: <432ce01b-bb6f-6f75-8060-9e95f7a10b6a@gmail.com> Date: Fri, 14 Oct 2022 11:11:26 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Always enable LRA Content-Language: en-US To: Richard Biener Cc: "Koning, Paul" , GCC Patches References: <5B041D75-19B2-4D8F-906F-CD524ACB5596@gmail.com> From: Jeff Law In-Reply-To: <5B041D75-19B2-4D8F-906F-CD524ACB5596@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 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 10/14/22 10:39, Richard Biener wrote: > >> Am 14.10.2022 um 16:40 schrieb Jeff Law via Gcc-patches : >> >>  >>> On 10/14/22 06:37, Koning, Paul wrote: >>> >>>>> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches wrote: >>>> >>>> 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_RaiseException': >>>>> /home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split insn >>>>> 141 | } >>>>> | ^ >>>>> (insn 69 256 327 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [12 S4 A32]) >>>>> (reg/f:SI 7 sp)) "/home/segher/src/gcc/libgcc/unwind.inc":118:12 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: >>>> >>>> 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 such operations are executed differently on different machine models. The solution I picked is to create two sets of machine-specific constraint codes, one for "register N" and the other for "autoinc/dec of any register other than N" and pairing those. (You can see this in pdp11.md, the mov definition.) >> I've long suspected the pdp11 was the inspiration for this restriction (I have memories of noting it before I relocated to Utah, so circa 1992). The key problem is the generic parts of the compiler don't know what the semantics ought to be -- so it's not obvious when they do a substitution whether or not the substitution of one reg for another is actually valid. It's important 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 standing wart that causes problems in other cases as well. >> >> That punts the problem to the backends and the H8 actually tries to deal with this restriction. Basically in the movxx pattern conditions, when the destination uses an autoinc addressing mode, the pattern's condition will check that the source register is different. I would expect other ports likely to do something similar. >> >> But that approach falls down with reload/lra doing substitutions without validating the result. I guess it might be possible to cobble together something with secondary reloads, but it's way way way down on my todo list. >> >> And yes, this case where the autoinc is on the destination works consistently 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 bit 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. *If* we went a route to relax the restriction (and I'm still not sure that's a good idea), we absolutely would have to document the semantics. jeff