From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 9E3933858C39 for ; Fri, 14 Oct 2022 21:15:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E3933858C39 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-pl1-x62b.google.com with SMTP id k9so5428366pll.11 for ; Fri, 14 Oct 2022 14:15:13 -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=E6BgNYCAW7A8rtSKfwf2Jb2mvU2T+Pa1vt0PqHlc9A8=; b=hpW/Ik8RyzLpDg9Ydx7HfQ8nfiV/+fsmuhUSahW2GYe8+UETJXgZ3528PgbQ7gCpLv L+DogRuO0o4EIYIBUKw7+qCJe6xjdkKwQXbkSZKoiZ8u3dKuNLv7rrfca7KHve4TOWlA detLGHhGS+O5FJZHIAvkTE95LG9nH4aGDkKvVMogJQQnxZ3v61xILlKw2FD6sTWhE7SX mg581/HpvsPJHXejTUPu9Kbe4r2/3ROQNBWxkylQ3O0xFIIytuanFOODSVAdB93w0s3V Z/CwpN3sm3CN5ZpagVNyoQl2C3iwi+JC2lzkOd03XNcRTdeLxrTIEv1y1WqLq1Qou16q 42vg== 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=E6BgNYCAW7A8rtSKfwf2Jb2mvU2T+Pa1vt0PqHlc9A8=; b=LwsZirhgqaNEiDovlQCFsHJ2ZwA/QVbIDEOnYSJurOW9ewQlLUsG8bYX88Csqedmka SYvkWh4Lo2B5eEy0IMG8DuUSKL4WiNPIZkzJukxAeNe7f3K7FBhoaIgkYf0UveFUL48R dVaEX2PhAgv7GVebfl5dHTpMpR13UlujdeS2UMkLQSjT51gMJ5Jw6+KyP3PkTZO1mJb9 Hw2APv4110K5t0e/WX1Oh6xz+RaS9HO38ercfR4odxUSyoP/4xiy72Kb2hsOEoCRJYa3 SXqoEBrZ+Vtm6nWGQB5+n2ptFiudZrFR+H3ZG11McRDm4QIBGQNwKtyuUSiRswIv4qvp EIfQ== X-Gm-Message-State: ACrzQf2MOdZDAN/+bDupNhyMY0DXpF5cQfH6eXp++reIqC1YWBoM/OCM xr4fuovjnv78YT6dYV32PCc= X-Google-Smtp-Source: AMsMyM6dB5nJ+PwKkqGQypxB8JnOZqLSwES0yOi6XOwsCkTDU1ehf8SVSf4QhjEER2Igs9BQ/4mLGg== X-Received: by 2002:a17:902:6b0a:b0:178:9a17:5b89 with SMTP id o10-20020a1709026b0a00b001789a175b89mr7046126plk.113.1665782112338; Fri, 14 Oct 2022 14:15:12 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id a11-20020aa7970b000000b00562664d5027sm2149919pfg.61.2022.10.14.14.15.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 14:15:11 -0700 (PDT) Message-ID: <92011b47-b665-ac84-232a-1d5fd5ab6e7f@gmail.com> Date: Fri, 14 Oct 2022 15:15:10 -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> From: Jeff Law In-Reply-To: <61B1E396-3A9D-4B99-8C78-FB6C3E0D1867@dell.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 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. Hence the h8300_move_ok test in the insn's condition where we can look at both operands to assess if it's a legitimate insn. > > As it stands, I find myself working hard to write MD code that accurately describes the rules of the machine, and for the core machinery to disregard those instructions is painful. No doubt. > > Is there a compelling argument for every case where LRA fails to obey the constraints? If not, can they just be called bugs and added to the to-be-fixed queue? There was in the reload days, though I honestly don't remember what it was, I'm much less familiar with LRA in this regard, but I trust Vlad's engineering skills and strongly believe that failing to recognize was done for a good reason. It's also worth repeating, we can get the same fundamental failure on the H8 with reload.  The testcase is different, but the core issue is the same.  We have a move with an autoinc destination and the same register is also used as a source operand incorerctly created by reload. What's a bit interesting here is the m68k doesn't do any kind of checking for these scenarios. It just accepts them and generates the obvious code.  I'm more tempted by the minute to do the same on the H8 :-) Jeff