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 095F938515DB for ; Thu, 2 Sep 2021 15:26:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 095F938515DB Received: by mail-pj1-x102e.google.com with SMTP id ot2-20020a17090b3b4200b0019127f8ed87so1461762pjb.1 for ; Thu, 02 Sep 2021 08:26:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:importance; bh=d4U7aidCO0CtmDbF+1Ti+z84TfZYEBl/1oKvA7aEg10=; b=QzGGh3vhVqwcC3x/blFT0j/mTuitD2WkQY+vD/jGaHmm1+I04x4a77rDKjeaPMWNdY cT29awDYuVLuqm7a5Oc9eG4xqqUsyDf7yhPyxg/wOMz2d7NussiSI5/a1dsYOVaGXhXe VeZ9gnsEjtM5mE8p2OpPCGYP3DrTktX1lD/3OICd5m/7BazGSVCR3Wljn6pZlYkIH2r9 QIrWAJJuZY3I3T63HHi9JtRHOtBgWvbCrxQqr8sj6V3xIJUUGnf8oxP7UXvFyk4vtepP Abh3k3wWlT2j8BTOOQUxgspz8rhuT25EkBW07JeHLUkH8SJHg8lvq/OAdbf/b+Pu5md9 m+LQ== X-Gm-Message-State: AOAM532ToCWJk86yeOut39tNTOqphj2aNSIesFZOpKi0if0cRmVrt1SO 9KdkN6xbzwH6jgZwuZTWH9c= X-Google-Smtp-Source: ABdhPJx8Wf+B23prJveNHxaxHOmAq5FY4TUTKv2B3C/7Tt6XwrlOSJROdZ/ESt2mpZHnCnzR2eUp8Q== X-Received: by 2002:a17:902:e88c:b0:136:e009:4c0d with SMTP id w12-20020a170902e88c00b00136e0094c0dmr3475950plg.11.1630596389910; Thu, 02 Sep 2021 08:26:29 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id t9sm2580817pfe.73.2021.09.02.08.26.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Sep 2021 08:26:29 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: , "Ulrich Weigand" References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> <18CA5177BA304CEAB8464FD24D0DF307@DESKTOP0OKG1VA> In-Reply-To: Subject: Re: s390 port Date: Fri, 3 Sep 2021 01:26:25 +1000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 15:26:41 -0000 >> I just checked my copy of s390.md and I don=E2=80=99t see >> LA being used for arithmetic. > This would be the "*la_31" and "*la_31_and" patterns. Sorry, I did a grep for =E2=80=9CLA=E2=80=9D, forgetting that s390.md doesn=E2=80=99t use uppercase instructions. > (Note that the addition is implicit in the use of > the "address_operand" constraint.) If it is an address we are talking about, then that LA instruction is going to work perfectly fine in AM24, AM31 and AM64, and in the AM64 case it is going to be the equivalent of AM32, so maybe the s390 port could have a =E2=80=9C-m32=E2=80=9D option for use when running 32-bit applications as AM64? >> If your copy of s390.md is using LA for arithmetic >> then would it be possible to have an option to >> use a normal mathematics instruction instead of >> LA? > LA was just an example. It doesn't usually make sense > to reason on an "use instruction X" basis, that's not > how compiler optimizations work. You rather start with > a set of semantic invariants and then make sure those > are preserved through all transformations. Ok, that=E2=80=99s above my head. > Therefore again my question, what is the actual goal > you want to achieve? I'm still not sure I understand > that ... I would like to know what is required to implement =E2=80=9C-m32=E2=80=9D in the S/390 target. I realize that z/Arch doesn=E2=80=99t have a specific AM32, but I don=E2=80=99t need a specific AM32. What would actually happen if you coded a =E2=80=9C-m32=E2=80=9D and then ran it in an AM64 environment? My experiments show =E2=80=9Cwith one single problem discovered so far, actually =E2=80=93m31 and =E2=80=93m32 are identical and work fine under AM64=E2=80=9D. >> Also, I just realized =E2=80=93 if GCC is using LA for maths >> for 32-bit registers, then values will be limited to >> 2 GiB instead of 4 GiB for unsigned, but that is not >> the case. > That's why GCC makes sure to only use the instruction > when a 31-bit addition is wanted. This can be the > case either when GCC can prove that the involved > operands are pointer values (which are by definition > restricted to 31-bit values in -m31 mode) The compiler doesn=E2=80=99t create a restriction there. It just generates a simple LA and it works differently depending on whether it is AM24/31/64. > or when > there is an explict 31-bit addition (using e.g. an > & 0x7fffffff) in the source code. Ok, thankyou, this is what I needed to know. I believe I would like to have a =E2=80=93m32 that drops this test. I don=E2=80=99t want GCC to assume that such an AND instruction can be implemented with the use of the =E2=80=9CLA=E2=80=9D instruction. I want to see an explicit =E2=80=9CN=E2=80=9D instruction used. Can I have this as part of =E2=80=9C-m32=E2=80=9D? Thanks. Paul.