From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id EE33F3858C52 for ; Sat, 15 Oct 2022 00:19:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE33F3858C52 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-x1032.google.com with SMTP id fw14so6310065pjb.3 for ; Fri, 14 Oct 2022 17:19:42 -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=giBfW+dqSV/94C8OaMrvBi49QnzvesGw5Wt2AHhDh0Q=; b=gQCMPSmHMLXNQaRvnzHzPy9s4i39LS/NJPqDU2p/Da9NCZktXJ1CRfWPVi7KHGVv9r OoI4UA7h+xNuyn2wo7PiWlP/lfcXjmTtkzU0wrbk5haA6rF58uFk5f2ZB3ITLsuLs7vO dyFrw/16R17h+IIDZlOSPQH4IqAJdF9FGoCCOoaEoUEgstwvr92J6BXtdeEFE4sNZZPl /JldJopzrc87rM/DAUDtJv8RmH1oQnJ96FkdTdH3MVPJw7Acex2apikl59H7JdvDxa/I WVgsycutnXi44v5yPLqY029d0yTZORpmvZM55xLZO1qzYV1sf5940/N6iEvWaMhE53q1 +y0w== 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=giBfW+dqSV/94C8OaMrvBi49QnzvesGw5Wt2AHhDh0Q=; b=ZY6cTMPrHcUuAIA34wdQYUB2sLBaj0aSoYbhHThjcHLEBF8EpQkDzNHYCsknx9iX57 G/qlhSWAwVFZOK9yrsoKfCyp4QBmLHFSVFiKp4U/jRXvatIFv1uX9MJ0LPdROIGFNC7U 8YzSh29H6e1vzYuhM6nmFcuXz56oL1efHPhpSZvz/8RbMZWa5+Jq0BNNuvIt1AVBbMcO aJj3Dmo3GcMnvOkWjWZ7gGjVbevbV6511ECzJDXGcxWZNpMMEMej4X/d/fMIsDu7IUyu zRa+jpSzO4ltkyoa/V314ZIzUrdCC7+6i2Wc5xsIES9UqWA7VeVFeIPE6XmPt6cXLbV8 yWFA== X-Gm-Message-State: ACrzQf1lgFiXfDvT6LxlwJCDm9mrIt3evZNyRM+EzoCb+k34U0fFt1eX 3t1+YFvYbB5s7mSMnmYAFmkQgLMK440= X-Google-Smtp-Source: AMsMyM6nJjMK4vgk1NziZ+0dYFCmGzV7vI1KG+B5imNFcRVpVXptGDOpR1jg01/SX38IloK17a7kMg== X-Received: by 2002:a17:902:e5c3:b0:176:d1b9:ee33 with SMTP id u3-20020a170902e5c300b00176d1b9ee33mr239856plf.122.1665793181836; Fri, 14 Oct 2022 17:19:41 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id d14-20020a170902b70e00b00178af82a08dsm2254192pls.91.2022.10.14.17.19.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 17:19:41 -0700 (PDT) Message-ID: Date: Fri, 14 Oct 2022 18:19:40 -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: "Koning, Paul" Cc: GCC Patches References: <40062fc8-42d4-40a7-cb53-250af8c98b89@gmail.com> <7C52148F-A6D1-475F-B19D-2C340770B8EC@dell.com> <61B1E396-3A9D-4B99-8C78-FB6C3E0D1867@dell.com> <92011b47-b665-ac84-232a-1d5fd5ab6e7f@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,BODY_8BITS,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 15:21, Koning, Paul wrote: > >> On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches wrote: >> >> >> On 10/14/22 11:36, Koning, Paul wrote: >>>> On Oct 14, 2022, at 1:10 PM, Jeff Law wrote: >>>> >>>> On 10/14/22 10:37, Koning, Paul wrote: >>>>>> ... >>>>>> 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. >>>>> Aren't the constraints enforced? My experience is that I was getting these bad addressing modes in some test programs, and that the constraints I created to make the requirement explicit cured that. Maybe I'm expecting too much from constraints, but my (admittedly inexperienced) understanding of them is that they inform reload what sort of things it can construct, and what it cannot. >>>> It's not really a constraint issue -- the pattern's condition would cause this not to recognize, but LRA doesn't re-recognize the insn. We might be able to hack something in the constraints to force a reload of the source operand in this case. Ugly, but a possibility. >>> I find it hard to cope with constraints that don't constrain. Minimally it should be clearly documented exactly what cases fail to obey the constraints and what a target writer can do to deal with those failures. >> Constraints have a purpose, but as I've noted, they really don't come into play here. Had LRA tried to see if what it created as a valid move insn, the backend would have said "nope, that's not valid". That's a stronger test than checking the constraints. If the insn is not valid according to its condition, then the constraints simply don't matter. >> >> I'm not aware of a case where constraints are failing to be obeyed and constraints simply aren't a viable solution here other than to paper over the problem and hope it doesn't show up elsewhere. >> >> Right now operand 0's constraint is "<" meaning pre-inc operand, operand 1 is "r". How would you define a new constraint for operand 1 that disallows overlap with operand 0 given that the H8 allows autoinc on any register operand? You can't look at operand 0 while processing the constraint for operand 1. Similarly if you try to define a new constraint for operand0 without looking at operand1. > Easy but cumbersome: define constraints for "register N" (for each N) and another set for "autoinc on any register other than N". In pdp11, I called these Z0, Z1... and Za, Zb... respectively. Then the insn gets constraints that look like "Z0,Z1,Z2..." and "Za, Zb, Zc..." for the two operands. As I said, see pdp11.md, the mov insn. It generally looks sound, but golly gee, this runs into the "reload doesn't validate insns problem"  if it's done in a reload tree rather than an lra tree.  We've got an insn with a pre-inc destination and a reg source.  The source pseudo doesn't get a hard reg, reload replaces the pseudo with a mem as expected. Reload finishes with something like this: (insn 100 98 101 15 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [8  S4 A32])         (mem/c:SI (plus:SI (reg/f:SI 7 sp)                 (const_int 8 [0x8])) [9 %sfp+-24 S4 A32])) "j.c":62:11 19 {*movsix}      (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])         (nil))) Which, isn't a valid instruction on the H8.  The insn's condition verifies that one of the two operands must be a REG.  But reload never bothered to re-recognize the insn after makng the substitution, then naturally it blows up in reload_cse with a constraint failure because the pre-inc destination constraints require a reg for the source operand.  But the real culprit here is reload making the substitution and not validing that the result is valid. Arggh! Which brings me back to pondering just removing the autoinc magic checking in the H8 port :-)  I've actually got that spinning in the tester just to see if there's any obvious fallout.  I've already spent more time on this than I can reasonably justify. Jeff