[{"id":3688379,"web_url":"http://patchwork.ozlabs.org/comment/3688379/","msgid":"<79d2f9d2-1647-4167-af49-7ea497feefc9@redhat.com>","list_archive_url":null,"date":"2026-05-08T12:23:46","subject":"Re: [PATCH] lra: Reloading section anchors","submitter":{"id":4455,"url":"http://patchwork.ozlabs.org/api/people/4455/","name":"Vladimir Makarov","email":"vmakarov@redhat.com"},"content":"On 5/6/26 5:21 AM, Stefan Schulze Frielinghaus wrote:\n> From: Stefan Schulze Frielinghaus \n>\n> Currently an \"entire\" address is reloaded even in cases where section\n> anchors are involved. This makes it harder to share section anchors\n> which is the whole point of them. For example, in cases where\n> offsetable MEMs are ok do not reload .LANCHOR42+offset but only\n> .LANCHOR42 and replace the address with the resulting reload register\n> and the offset. As a consequence subsequent passes only have to deal\n> with register equivalences in order to share section anchors. For\n> example\n\n\nI thought how to fix this in another place as LRA is already too \ncomplicated.  It could be fixed in some machined-dependent pass or in \nsplit1.  Adding the pass is overkill and fix in split1 would be ok if \nthe target would work with memory via few insns (e.g. only via \nload/store insns).  So probably LRA is the best place to fix this problem.\n\n\n> double x;\n> double y;\n>\n> double foo ()\n> {\n> return x + y;\n> }\n>\n> With this patch, after LRA we have\n>\n> 20: %r1:DI=`*.LANCHOR0'\n> 17: %f0:DF=[%r1:DI]\n> 19: %r1:DI=`*.LANCHOR0'\n> 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n>\n> and after postreload\n>\n> 20: %r1:DI=`*.LANCHOR0'\n> 17: %f0:DF=[%r1:DI]\n> 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n>\n> Of course, this was a lucky case since both reloads referred to the very\n> same register which allows for trivial removal of insn 19. At least in\n> cases like demonstrated by the new test section-anchors-4.c we are\n> guaranteed to re-use the reload for a single insn.\n>\n> Before testing this patch for multiple targets, I'm wondering whether\n> there is even a way to re-use reloads during LRA across insns (like an\n> equiv) such that we wouldn't depend on subsequent passes?\n\nLRA reuses the reload pseudo generated for one insn (please see usage of \ncurr_insn_input_reloads).  The problem in not reusing reload pseudo for \nthe above example is that because reload for anchor occurs from \ndifferent insns.  First LRA reloads [*.LANCHOR0] (insn 17 generated to \nsatisfy reg constraint in insn 12), then the anchor (from insn 17 ), and \nthen reload *.LANCHOR0 from 2nd op of insn 12.  But I'd not be worry \nthat the reload pseudos get different hard regs.  Knowing how assigning \nhard regs works in LRA I see very small probability that the pseduos get \ndifferent regs.\n\nBTW I did not reproduce the testcase situation w/o -march options (the \nanchor in this case already in a pseudo before RA).  But -march=z13 \nreproduces it.  So probably you need to add this option to the test.\n\nSo the patch (with -march=z13 or other one reproducing the situation as \nadditional option for the test) is ok for me. Thank you.\n\n> ---\n> gcc/lra-constraints.cc | 30 +++++++++++++++++++\n> .../gcc.target/s390/section-anchors-4.c | 25 ++++++++++++++++\n> 2 files changed, 55 insertions(+)\n> create mode 100644 gcc/testsuite/gcc.target/s390/section-anchors-4.c\n>\n> diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc\n> index ccd68efc956..6779dfee020 100644\n> --- a/gcc/lra-constraints.cc\n> +++ b/gcc/lra-constraints.cc\n> @@ -4839,6 +4839,36 @@ curr_insn_transform (bool check_only_p)\n> \t new_reg = emit_inc (rclass, *loc,\n> \t\t\t\t/* This value does not matter for MODIFY. */\n> \t\t\t\tGET_MODE_SIZE (GET_MODE (op)));\n> +\t /* Try to pull out section anchors. For example, instead of\n> +\t reloading an \"entire\" address like .LANCHOR42+offset only reload\n> +\t .LANCHOR42 and use the new reload register as the base register.\n> +\t This allows following optimizations to share section anchors and\n> +\t remove redundant loads. */\n> +\t else if (GET_CODE (*loc) == CONST\n> +\t\t && GET_CODE (XEXP (*loc, 0)) == PLUS\n> +\t\t && GET_CODE (XEXP (XEXP (*loc, 0), 0)) == SYMBOL_REF\n> +\t\t && SYMBOL_REF_ANCHOR_P (XEXP (XEXP (*loc, 0), 0))\n> +\t\t && CONST_INT_P (XEXP (XEXP (*loc, 0), 1))\n> +\t\t /* Some offsets are valid in conjunction with a symbol and\n> +\t\t invalid in conjunction with a register. Thus, pull out\n> +\t\t the anchor only in case the offset is a valid anchor\n> +\t\t offset. */\n> +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> +\t\t >= targetm.min_anchor_offset\n> +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> +\t\t <= targetm.max_anchor_offset)\n> +\t {\n> +\t rtx anchor = XEXP (XEXP (*loc, 0), 0);\n> +\t rtx offset = XEXP (XEXP (*loc, 0), 1);\n> +\n> +\t if (get_reload_reg (OP_IN, Pmode, anchor, rclass,\n> +\t\t\t\t NULL, false, false,\n> +\t\t\t\t \"offsetable address\", &new_reg))\n> +\t\t lra_emit_move (new_reg, anchor);\n> +\n> +\t\tnew_reg = gen_rtx_PLUS (Pmode, new_reg, offset);\n> +\t\tlra_assert (valid_address_p (Pmode, new_reg, MEM_ADDR_SPACE (op)));\n> +\t }\n> \t else if (get_reload_reg (OP_IN, Pmode, *loc, rclass,\n> \t\t\t\t NULL, false, false,\n> \t\t\t\t \"offsetable address\", &new_reg))\n> diff --git a/gcc/testsuite/gcc.target/s390/section-anchors-4.c b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> new file mode 100644\n> index 00000000000..0b4cd081c61\n> --- /dev/null\n> +++ b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> @@ -0,0 +1,25 @@\n> +/* { dg-do compile } */\n> +/* { dg-options \"-O2 -fdump-rtl-ira-slim -fdump-rtl-reload-slim\" } */\n> +/* { dg-final { scan-assembler-times \"\\tlarl\\t\" 1 } } */\n> +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[`\\\\\\*.LANCHOR0'\\\\\\],\\\\\\[const\\\\\\(`\\\\\\*.LANCHOR0'\\\\\\+0x8\\\\\\)\\\\\\]\\\\\\)\" \"ira\" } } */\n> +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[(%r\\[1-9\\]\\[0-9\\]?):DI\\\\\\],\\\\\\[\\\\1:DI\\\\\\+0x8\\\\\\]\\\\\\)\" \"reload\" } } */\n> +\n> +/* Ensure that we get the same reload register for the second memory operand.\n> + Prior LRA we have\n> +\n> + 55: %cc:CCZ=cmp([`*.LANCHOR0'],[const(`*.LANCHOR0'+0x8)])\n> +\n> + and after LRA\n> +\n> + 59: %r1:DI=`*.LANCHOR0'\n> + 55: %cc:CCZ=cmp([%r1:DI],[%r1:DI+0x8]) */\n> +\n> +long x, y;\n> +\n> +long\n> +foo (void)\n> +{\n> + if (x == y)\n> + return 42;\n> + return 0;\n> +}","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=XlbmUyc5;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=XlbmUyc5","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","sourceware.org; arc=none smtp.remote-ip=170.10.133.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gBpGY5bm3z1yKd\n\tfor ; Fri, 08 May 2026 22:24:52 +1000 (AEST)","from vm01.sourceware.org (localhost [IPv6:::1])\n\tby sourceware.org (Postfix) with ESMTP id 204524BA2E0D\n\tfor ; Fri, 8 May 2026 12:24:50 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n by sourceware.org (Postfix) with ESMTP id E6BBE4BA2E18\n for ; Fri, 8 May 2026 12:23:54 +0000 (GMT)","from mail-qk1-f199.google.com (mail-qk1-f199.google.com\n [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-120-GfcrQxw6PS-BkZVmTVppGA-1; Fri, 08 May 2026 08:23:53 -0400","by mail-qk1-f199.google.com with SMTP id\n af79cd13be357-8eb55e55394so390181285a.1\n for ; Fri, 08 May 2026 05:23:53 -0700 (PDT)","from [192.168.0.111] (192-0-141-76.cpe.teksavvy.com. [192.0.141.76])\n by smtp.gmail.com with ESMTPSA id\n af79cd13be357-907b87c3e01sm204456085a.26.2026.05.08.05.23.51\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 08 May 2026 05:23:51 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 204524BA2E0D","OpenDKIM Filter v2.11.0 sourceware.org E6BBE4BA2E18"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org E6BBE4BA2E18","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org E6BBE4BA2E18","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778243035; cv=none;\n b=SDzI63L92witq8i7sAiwu6S6ORnZ8uu6yzRBKr2Oaf0W+uCcjQAWCayVb0kYsEh8knjtIZh1n7980mxBFXVm6s6xvY+aMopxxbSmEiE+V+teDRzdGzLknPACPUmWg0vcz2Fq92vzmoG6nDlQ3ASB8f//DR6WM/Pihk8tDpvL8T4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1778243035; c=relaxed/simple;\n bh=QQ1xkthDj4fCEU+oVCfnvDPutVaQrGaBKL9oEMz0bes=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=qH4Z7rhvH7AJhg3RUo03rQ0OL5KbRWDqeOsPPH84T6DLJeEzV3Q7vJWpdEDf/GjBBmuLygbPkr4m9SNdHNfu5aYFkFYqqGatmjFxPZVaMwfA3hfvjZ5BGg899+5lEVpSt2XXh7JFlKfILxUJgCX4fYB9u5orjTcag+6V0uYmTVo=","ARC-Authentication-Results":"i=1; sourceware.org;\n dkim=pass (1024-bit key, unprotected)\n header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=XlbmUyc5","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1778243034;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=+AeQXQD90LvkyhhrxClgzWE3dJZWg5P56Q0vMY/3k3c=;\n b=XlbmUyc5LHnrZ6yLbghVxy3Dzmps08i//TKzCMuvAIBQ3j/hRh3TICEAwWNY6xEMfRivlk\n iCOzgLTSWFzNg7RBYRKAStNvw5//ZlwjEMMiUnf3cS3aE8Gjo7tKkffcngI9oHsGvThXq9\n 8qfrJl/Q3fzvFBpPXbxh7P0b6KCTQQg=","X-MC-Unique":"GfcrQxw6PS-BkZVmTVppGA-1","X-Mimecast-MFC-AGG-ID":"GfcrQxw6PS-BkZVmTVppGA_1778243033","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1778243033; x=1778847833;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=+AeQXQD90LvkyhhrxClgzWE3dJZWg5P56Q0vMY/3k3c=;\n b=JYWWfcE3N3PUhwRxNCndbxQTBpmLXNmYFkUFyVXRnGovRX5UyKwIBqTVL4af88QK/w\n 8uewRBa7Eu4l11Cq/g/fE5ov43nbHAlICx6uILzG2AKKNd5QXyYKGGLfz++NCHucN5xS\n P6CIuz86oWYnfax9syTmSK2GYWQJuKfHPb90yofWEnUEujgZ1b4bNsC6x69BBw98K28L\n 5eYgTiS1C5lndkk0KMFrDc7ecgrL9nvxiwzozTEZfNoZ1cbhx4yyCcnrYY7F17uLXIUr\n BfGGIxK0/hJaFayRtwWoHpEnc30oypllDsx4brTby+XyLxMFgRLLdxhtl51gVxfGOLNc\n cqWg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ84Pzm7xq1McO9BAMmZAEt6XJHjdaG6+ZGa0ZqSLB6mFjHlFBksKoeLymbS/Fi351sTPie13Ztz/dt1dA==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YxmTk/5hdRkgHusGDUbOCn1s7ZaqrTbHInHWI7haTkg/XVibbt2\n uOu1N/X2YPD9JXiaKpxmpSforKGZeCvjM97SLhd1d1XqRKVGVuqI/wiFpHBGYkF9ldeaD5nIBJW\n P/R7dbLkCYoUpovMv6KuBAlofHI8mzvs1Hn//w62ofprUScfY/tT1ZfrzMqk=","X-Gm-Gg":"AeBDiet9LXngWUeH/Rt8EcOkEUail2VqA382dwMlg3uX0blpy5r8Q9AIAwBvvKOOsmP\n S9x7yALyXKzaOUeedr/5zz8X1yi7ibqxia1VtqD3VfAwbDXkMxmbUdPyjfNDd+ChJB8P7LLBP7+\n nW/Y4G3kdiToPI0oAjCdkJf40tpFXhhLkhq3dtT2PBhqPgHhSFooiv7Pbl5cyIdFuqLIbXT0bJO\n bxB7H1ZW8onhw41djfvxc2AtHrem7s9SZTG2xEx4v+U7Gl0P+Gc4imDlZag5ucb48u6546UtpBS\n 8EhIAt5rNfiPIPDDkWbKdoLvb1Zx69phWgk1Ni7waUqK3dFUEaNpr1Co1ikMuZFvpyfkNo7IYKY\n dBQMK8ZYGZuTCeURoPT+oKysUZwmuH0dBY7w8mN/cHuUu2gjv6bnjTgPhH9u2pDDITQ==","X-Received":["by 2002:a05:620a:461e:b0:8ec:c4a7:f8e5 with SMTP id\n af79cd13be357-907bad06b07mr343256585a.31.1778243032501;\n Fri, 08 May 2026 05:23:52 -0700 (PDT)","by 2002:a05:620a:461e:b0:8ec:c4a7:f8e5 with SMTP id\n af79cd13be357-907bad06b07mr343250285a.31.1778243031854;\n Fri, 08 May 2026 05:23:51 -0700 (PDT)"],"Message-ID":"<79d2f9d2-1647-4167-af49-7ea497feefc9@redhat.com>","Date":"Fri, 8 May 2026 08:23:46 -0400","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] lra: Reloading section anchors","To":"Stefan Schulze Frielinghaus ,\n gcc-patches@gcc.gnu.org","References":"<20260506092124.2542192-1-stefansf@linux.ibm.com>","From":"Vladimir Makarov ","In-Reply-To":"<20260506092124.2542192-1-stefansf@linux.ibm.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"dWGQFJxm-PjQMQeA24EF37bSk2lT8B8FJqlYhtD6FsU_1778243033","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3689632,"web_url":"http://patchwork.ozlabs.org/comment/3689632/","msgid":"","list_archive_url":null,"date":"2026-05-11T19:40:14","subject":"Re: [PATCH] lra: Reloading section anchors","submitter":{"id":78338,"url":"http://patchwork.ozlabs.org/api/people/78338/","name":"Stefan Schulze Frielinghaus","email":"stefansf@linux.ibm.com"},"content":"On Fri, May 08, 2026 at 08:23:46AM -0400, Vladimir Makarov wrote:\n> \n> On 5/6/26 5:21 AM, Stefan Schulze Frielinghaus wrote:\n> > From: Stefan Schulze Frielinghaus \n> > \n> > Currently an \"entire\" address is reloaded even in cases where section\n> > anchors are involved. This makes it harder to share section anchors\n> > which is the whole point of them. For example, in cases where\n> > offsetable MEMs are ok do not reload .LANCHOR42+offset but only\n> > .LANCHOR42 and replace the address with the resulting reload register\n> > and the offset. As a consequence subsequent passes only have to deal\n> > with register equivalences in order to share section anchors. For\n> > example\n> \n> \n> I thought how to fix this in another place as LRA is already too\n> complicated.  It could be fixed in some machined-dependent pass or in\n> split1.  Adding the pass is overkill and fix in split1 would be ok if the\n> target would work with memory via few insns (e.g. only via load/store\n> insns).  So probably LRA is the best place to fix this problem.\n> \n> \n> > double x;\n> > double y;\n> > \n> > double foo ()\n> > {\n> > return x + y;\n> > }\n> > \n> > With this patch, after LRA we have\n> > \n> > 20: %r1:DI=`*.LANCHOR0'\n> > 17: %f0:DF=[%r1:DI]\n> > 19: %r1:DI=`*.LANCHOR0'\n> > 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n> > \n> > and after postreload\n> > \n> > 20: %r1:DI=`*.LANCHOR0'\n> > 17: %f0:DF=[%r1:DI]\n> > 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n> > \n> > Of course, this was a lucky case since both reloads referred to the very\n> > same register which allows for trivial removal of insn 19. At least in\n> > cases like demonstrated by the new test section-anchors-4.c we are\n> > guaranteed to re-use the reload for a single insn.\n> > \n> > Before testing this patch for multiple targets, I'm wondering whether\n> > there is even a way to re-use reloads during LRA across insns (like an\n> > equiv) such that we wouldn't depend on subsequent passes?\n\nMeanwhile successfully bootstrapped and regtested on\n\n- aarch64-unknown-linux-gnu\n- s390x-ibm-linux-gnu\n- x86_64-pc-linux-gnu\n\nFor powerpc64le-unknown-linux-gnu there is a new test failure:\n\nFAIL: gcc.target/powerpc/pr94740.c (internal compiler error: in extract_constrain_insn, at recog.cc:2795)\n\nPreviously the whole address was reloaded which means we ended up with:\n\n 18: %2:DI=const(`*.LANCHOR0'+0x4)\n 7: %3:SI=bswap([%2:DI])\n\nand with this patch we bail out during LRA for\n\n 18: %2:DI=`*.LANCHOR0'\n 7: %3:SI=bswap([%2:DI+0x4])\n\nwith\n\npr94740.c:11:1: error: insn does not satisfy its constraints:\n 11 | }\n | ^\n(insn 7 18 13 2 (set (reg:SI 3 3 [orig:119 _3 ] [119])\n (bswap:SI (mem/c:SI (plus:DI (reg:DI 2 2 [127])\n (const_int 4 [0x4])) [1 array[1]+0 S4 A32]))) \"pr94740.c\":10:10 143 {bswapsi2_load}\n (nil))\n\nThe insn definition is:\n\n(define_insn \"bswap2_load\"\n [(set (match_operand:HSI 0 \"gpc_reg_operand\" \"=r\")\n (bswap:HSI (match_operand:HSI 1 \"memory_operand\" \"Z\")))]\n \"\"\n \"lbrx %0,%y1\"\n [(set_attr \"type\" \"load\")])\n\nand the important part of the constraint Z is\n\n(define_special_predicate \"indexed_or_indirect_address\"\n (and (match_test \"REG_P (op)\n || (GET_CODE (op) == PLUS\n /* Omit testing REG_P (XEXP (op, 0)). */\n && REG_P (XEXP (op, 1)))\")\n (match_operand 0 \"address_operand\")))\n\nwhich doesn't accept offsettable addresses. At this point I'm not\nentirely sure what the contract between targets and LRA is. My reading\nso far was that due to goal_alt_offmemok[i] it is safe to use\noffsettable addresses.\n\n> \n> LRA reuses the reload pseudo generated for one insn (please see usage of\n> curr_insn_input_reloads).  The problem in not reusing reload pseudo for the\n> above example is that because reload for anchor occurs from different\n> insns.  First LRA reloads [*.LANCHOR0] (insn 17 generated to satisfy reg\n> constraint in insn 12), then the anchor (from insn 17 ), and then reload\n> *.LANCHOR0 from 2nd op of insn 12.  But I'd not be worry that the reload\n> pseudos get different hard regs.  Knowing how assigning hard regs works in\n> LRA I see very small probability that the pseduos get different regs.\n> \n> BTW I did not reproduce the testcase situation w/o -march options (the\n> anchor in this case already in a pseudo before RA).  But -march=z13\n> reproduces it.  So probably you need to add this option to the test.\n\nAhh right, I tested this patch on top of a private one where the test\ncase is successful for many archs. Currently it is failing because\nthe last alternative of insn cmpdi_cct is rejected for vanilla and\naccepted for my private patch. It will take me some time to polish up\nthe private patch. Thus, I think we have two options here. Proceed\nwith this patch without a test case, or wait until the other patch is\nready. I'm fine either way.\n\nI was afraid of a flaky test and deliberately chose this test since it\nguarantees that the section anchor ends up in the very same reload\nregister. Maybe I should be more brave here ;-)\n\nThanks,\nStefan\n\n> \n> So the patch (with -march=z13 or other one reproducing the situation as\n> additional option for the test) is ok for me. Thank you.\n> \n> > ---\n> > gcc/lra-constraints.cc | 30 +++++++++++++++++++\n> > .../gcc.target/s390/section-anchors-4.c | 25 ++++++++++++++++\n> > 2 files changed, 55 insertions(+)\n> > create mode 100644 gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > \n> > diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc\n> > index ccd68efc956..6779dfee020 100644\n> > --- a/gcc/lra-constraints.cc\n> > +++ b/gcc/lra-constraints.cc\n> > @@ -4839,6 +4839,36 @@ curr_insn_transform (bool check_only_p)\n> > \t new_reg = emit_inc (rclass, *loc,\n> > \t\t\t\t/* This value does not matter for MODIFY. */\n> > \t\t\t\tGET_MODE_SIZE (GET_MODE (op)));\n> > +\t /* Try to pull out section anchors. For example, instead of\n> > +\t reloading an \"entire\" address like .LANCHOR42+offset only reload\n> > +\t .LANCHOR42 and use the new reload register as the base register.\n> > +\t This allows following optimizations to share section anchors and\n> > +\t remove redundant loads. */\n> > +\t else if (GET_CODE (*loc) == CONST\n> > +\t\t && GET_CODE (XEXP (*loc, 0)) == PLUS\n> > +\t\t && GET_CODE (XEXP (XEXP (*loc, 0), 0)) == SYMBOL_REF\n> > +\t\t && SYMBOL_REF_ANCHOR_P (XEXP (XEXP (*loc, 0), 0))\n> > +\t\t && CONST_INT_P (XEXP (XEXP (*loc, 0), 1))\n> > +\t\t /* Some offsets are valid in conjunction with a symbol and\n> > +\t\t invalid in conjunction with a register. Thus, pull out\n> > +\t\t the anchor only in case the offset is a valid anchor\n> > +\t\t offset. */\n> > +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> > +\t\t >= targetm.min_anchor_offset\n> > +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> > +\t\t <= targetm.max_anchor_offset)\n> > +\t {\n> > +\t rtx anchor = XEXP (XEXP (*loc, 0), 0);\n> > +\t rtx offset = XEXP (XEXP (*loc, 0), 1);\n> > +\n> > +\t if (get_reload_reg (OP_IN, Pmode, anchor, rclass,\n> > +\t\t\t\t NULL, false, false,\n> > +\t\t\t\t \"offsetable address\", &new_reg))\n> > +\t\t lra_emit_move (new_reg, anchor);\n> > +\n> > +\t\tnew_reg = gen_rtx_PLUS (Pmode, new_reg, offset);\n> > +\t\tlra_assert (valid_address_p (Pmode, new_reg, MEM_ADDR_SPACE (op)));\n> > +\t }\n> > \t else if (get_reload_reg (OP_IN, Pmode, *loc, rclass,\n> > \t\t\t\t NULL, false, false,\n> > \t\t\t\t \"offsetable address\", &new_reg))\n> > diff --git a/gcc/testsuite/gcc.target/s390/section-anchors-4.c b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > new file mode 100644\n> > index 00000000000..0b4cd081c61\n> > --- /dev/null\n> > +++ b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > @@ -0,0 +1,25 @@\n> > +/* { dg-do compile } */\n> > +/* { dg-options \"-O2 -fdump-rtl-ira-slim -fdump-rtl-reload-slim\" } */\n> > +/* { dg-final { scan-assembler-times \"\\tlarl\\t\" 1 } } */\n> > +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[`\\\\\\*.LANCHOR0'\\\\\\],\\\\\\[const\\\\\\(`\\\\\\*.LANCHOR0'\\\\\\+0x8\\\\\\)\\\\\\]\\\\\\)\" \"ira\" } } */\n> > +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[(%r\\[1-9\\]\\[0-9\\]?):DI\\\\\\],\\\\\\[\\\\1:DI\\\\\\+0x8\\\\\\]\\\\\\)\" \"reload\" } } */\n> > +\n> > +/* Ensure that we get the same reload register for the second memory operand.\n> > + Prior LRA we have\n> > +\n> > + 55: %cc:CCZ=cmp([`*.LANCHOR0'],[const(`*.LANCHOR0'+0x8)])\n> > +\n> > + and after LRA\n> > +\n> > + 59: %r1:DI=`*.LANCHOR0'\n> > + 55: %cc:CCZ=cmp([%r1:DI],[%r1:DI+0x8]) */\n> > +\n> > +long x, y;\n> > +\n> > +long\n> > +foo (void)\n> > +{\n> > + if (x == y)\n> > + return 42;\n> > + return 0;\n> > +}\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=m5aBgJ76;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=m5aBgJ76","sourceware.org;\n dmarc=none (p=none dis=none) header.from=linux.ibm.com","sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com","sourceware.org; arc=none smtp.remote-ip=148.163.156.1"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gDqpS6gsXz1yHW\n\tfor ; Tue, 12 May 2026 05:41:03 +1000 (AEST)","from vm01.sourceware.org (localhost [IPv6:::1])\n\tby sourceware.org (Postfix) with ESMTP id 8A1774BB3BEA\n\tfor ; Mon, 11 May 2026 19:41:01 +0000 (GMT)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n by sourceware.org (Postfix) with ESMTPS id 494F24BB3BB5\n for ; Mon, 11 May 2026 19:40:20 +0000 (GMT)","from pps.filterd (m0353729.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 64BDKwkK3470197; Mon, 11 May 2026 19:40:19 GMT","from ppma23.wdc07v.mail.ibm.com\n (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4e1vkqsv38-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Mon, 11 May 2026 19:40:18 +0000 (GMT)","from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1])\n by ppma23.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id\n 64BJdk78015796;\n Mon, 11 May 2026 19:40:17 GMT","from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226])\n by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4e3nfgg02b-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Mon, 11 May 2026 19:40:17 +0000 (GMT)","from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com\n [10.20.54.100])\n by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 64BJeF7B46072260\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Mon, 11 May 2026 19:40:15 GMT","from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id A419320043;\n Mon, 11 May 2026 19:40:15 +0000 (GMT)","from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 62CF620040;\n Mon, 11 May 2026 19:40:15 +0000 (GMT)","from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown\n [9.87.130.198])\n by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;\n Mon, 11 May 2026 19:40:15 +0000 (GMT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 8A1774BB3BEA","OpenDKIM Filter v2.11.0 sourceware.org 494F24BB3BB5"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 494F24BB3BB5","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 494F24BB3BB5","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778528420; cv=none;\n b=LqseDAF8+s46jeOsN7aIQvEAm5jGw5SEI4pAOQG1eQ7Q9riuCJINxa9vAsFSQ+TPkShUelv+G2BjUeO9FYma+0jIV+tqzjchQhZEPtOLQxz5eGx0doj6gEgHmyEVpRHMmMsskCA353p95fxB0ri8EoGXkVCMHji+GY7jGgZ8OsU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1778528420; c=relaxed/simple;\n bh=kY5LsLiYNjfEgwqJO6e8OkDVbhSewFCl3PjCajzkh/I=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=kCYpxpYfJJrJsMJKhT47Iua1Is5SJonHPcHqVXm7GJz0M9fD9haniXp8g1IntVxoPRg+e2JA2HFecNKRDYOsbLEuwcpjjspjsb9rBwcou7mzGTq+LWPS2fcmzN4ScEDhMGJQq22yxkFF/EP762+DShqsZdbKqzJ+jssko3wer3c=","ARC-Authentication-Results":"i=1; sourceware.org;\n dkim=pass (2048-bit key, unprotected)\n header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1\n header.b=m5aBgJ76","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n :content-transfer-encoding:content-type:date:from:in-reply-to\n :message-id:mime-version:references:subject:to; s=pp1; bh=z3lTlE\n hQZyfDfqfT7sSvm+kARUkDl//JVoGQbcZBkr0=; b=m5aBgJ76vHq8WW3BoZVSdX\n r75Hu0kYdyjl7yCi4d2G9TbzCTO4U7uHshe7RQ6nkk59jIsj+RXjp+4KbdsXphlF\n 9InJA/tyacZ8IUcDdkgdhK5FXlHcM9u24wRgjbdPDP7Ysdc7yzw1vzg73JUaQdC9\n yNqnsMwFxKCNTLf0sdMyRm3MI3wUiXVzPoMiUk+7LIw2m28/dMesm5L+N02A1L+E\n FeaN1OHZlUta4jTNByX+r/MXBBTfTzB31vDtilz6VFnKiipg4BOTeeQ5lQZz5Iuf\n cleOfsjkjtRSUpUnVkDcsDUihUrFlzuHjsotF9PF979TnelZ/WDfDrfT06z83MIg\n ==","Date":"Mon, 11 May 2026 21:40:14 +0200","From":"Stefan Schulze Frielinghaus ","To":"Vladimir Makarov ","Cc":"gcc-patches@gcc.gnu.org","Subject":"Re: [PATCH] lra: Reloading section anchors","Message-ID":"","References":"<20260506092124.2542192-1-stefansf@linux.ibm.com>\n <79d2f9d2-1647-4167-af49-7ea497feefc9@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<79d2f9d2-1647-4167-af49-7ea497feefc9@redhat.com>","X-TM-AS-GCONF":"00","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNTExMDIwOCBTYWx0ZWRfXwWseUeDdHy0I\n MH6rZo6APMRPI8HAYySlEmqvVGR1SRapis324yvk1BCgYcCpjWY8ETRvJR/5rFKCf5bsuHHjvV/\n lPRRFB9yJ41jclSTQSBVZZYo0L2hZjAyUeVO4hLSsC2zdUw+kcqfIfxpU2hVF5vu7N63iUyRz6o\n fSsPE2xUSJ/hoKixt7ggdOA7G3g/kB+ghZa2hB7rJdp9IRtHy8tlB1/4F4hrsgJ/UsTyuQh6FgL\n BQpTveMGLRNp2V53UaMz04IXp+gaDGBSj2va4zO/h91iOQxfBh1WWrPhJ648RmXNfnzCTCv2aaN\n XFcM1NIJLJrOpJIfVfRa4Qcr5wbwlinYIXnP4mPjwGSNu/GJHned8Qr4iJmHx6ly6jpOHA0zTwt\n otCfS++yuhBK+cvZHghh/WU/fjsLggekOgGshWyA7bGUB7uz4Gg+SPYKWT2v3WNT906NwosnPja\n EuRBANoTuDrxEkIZh0A==","X-Authority-Analysis":"v=2.4 cv=OaWoyBTY c=1 sm=1 tr=0 ts=6a0230a2 cx=c_pps\n a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17\n a=8nJEP1OIZ-IA:10 a=NGcC8JguVDcA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=mDV3o1hIAAAA:8\n a=bJPNx8F0d7FIqhnF3-sA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10","X-Proofpoint-ORIG-GUID":"e43-52hNh0h5jsSTVmoIjeSNjIu0jZHL","X-Proofpoint-GUID":"e43-52hNh0h5jsSTVmoIjeSNjIu0jZHL","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-05-11_05,2026-05-08_02,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n malwarescore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0\n phishscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0\n adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=\n route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000\n definitions=main-2605110208","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3690954,"web_url":"http://patchwork.ozlabs.org/comment/3690954/","msgid":"","list_archive_url":null,"date":"2026-05-13T15:39:55","subject":"Re: [PATCH] lra: Reloading section anchors","submitter":{"id":78338,"url":"http://patchwork.ozlabs.org/api/people/78338/","name":"Stefan Schulze Frielinghaus","email":"stefansf@linux.ibm.com"},"content":"On Mon, May 11, 2026 at 09:40:15PM +0200, Stefan Schulze Frielinghaus wrote:\n> On Fri, May 08, 2026 at 08:23:46AM -0400, Vladimir Makarov wrote:\n> > \n> > On 5/6/26 5:21 AM, Stefan Schulze Frielinghaus wrote:\n> > > From: Stefan Schulze Frielinghaus \n> > > \n> > > Currently an \"entire\" address is reloaded even in cases where section\n> > > anchors are involved. This makes it harder to share section anchors\n> > > which is the whole point of them. For example, in cases where\n> > > offsetable MEMs are ok do not reload .LANCHOR42+offset but only\n> > > .LANCHOR42 and replace the address with the resulting reload register\n> > > and the offset. As a consequence subsequent passes only have to deal\n> > > with register equivalences in order to share section anchors. For\n> > > example\n> > \n> > \n> > I thought how to fix this in another place as LRA is already too\n> > complicated.  It could be fixed in some machined-dependent pass or in\n> > split1.  Adding the pass is overkill and fix in split1 would be ok if the\n> > target would work with memory via few insns (e.g. only via load/store\n> > insns).  So probably LRA is the best place to fix this problem.\n> > \n> > \n> > > double x;\n> > > double y;\n> > > \n> > > double foo ()\n> > > {\n> > > return x + y;\n> > > }\n> > > \n> > > With this patch, after LRA we have\n> > > \n> > > 20: %r1:DI=`*.LANCHOR0'\n> > > 17: %f0:DF=[%r1:DI]\n> > > 19: %r1:DI=`*.LANCHOR0'\n> > > 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n> > > \n> > > and after postreload\n> > > \n> > > 20: %r1:DI=`*.LANCHOR0'\n> > > 17: %f0:DF=[%r1:DI]\n> > > 12: {%f0:DF=%f0:DF+[%r1:DI+0x8];clobber %cc:CC;}\n> > > \n> > > Of course, this was a lucky case since both reloads referred to the very\n> > > same register which allows for trivial removal of insn 19. At least in\n> > > cases like demonstrated by the new test section-anchors-4.c we are\n> > > guaranteed to re-use the reload for a single insn.\n> > > \n> > > Before testing this patch for multiple targets, I'm wondering whether\n> > > there is even a way to re-use reloads during LRA across insns (like an\n> > > equiv) such that we wouldn't depend on subsequent passes?\n> \n> Meanwhile successfully bootstrapped and regtested on\n> \n> - aarch64-unknown-linux-gnu\n> - s390x-ibm-linux-gnu\n> - x86_64-pc-linux-gnu\n> \n> For powerpc64le-unknown-linux-gnu there is a new test failure:\n> \n> FAIL: gcc.target/powerpc/pr94740.c (internal compiler error: in extract_constrain_insn, at recog.cc:2795)\n> \n> Previously the whole address was reloaded which means we ended up with:\n> \n> 18: %2:DI=const(`*.LANCHOR0'+0x4)\n> 7: %3:SI=bswap([%2:DI])\n> \n> and with this patch we bail out during LRA for\n> \n> 18: %2:DI=`*.LANCHOR0'\n> 7: %3:SI=bswap([%2:DI+0x4])\n> \n> with\n> \n> pr94740.c:11:1: error: insn does not satisfy its constraints:\n> 11 | }\n> | ^\n> (insn 7 18 13 2 (set (reg:SI 3 3 [orig:119 _3 ] [119])\n> (bswap:SI (mem/c:SI (plus:DI (reg:DI 2 2 [127])\n> (const_int 4 [0x4])) [1 array[1]+0 S4 A32]))) \"pr94740.c\":10:10 143 {bswapsi2_load}\n> (nil))\n> \n> The insn definition is:\n> \n> (define_insn \"bswap2_load\"\n> [(set (match_operand:HSI 0 \"gpc_reg_operand\" \"=r\")\n> (bswap:HSI (match_operand:HSI 1 \"memory_operand\" \"Z\")))]\n> \"\"\n> \"lbrx %0,%y1\"\n> [(set_attr \"type\" \"load\")])\n> \n> and the important part of the constraint Z is\n> \n> (define_special_predicate \"indexed_or_indirect_address\"\n> (and (match_test \"REG_P (op)\n> || (GET_CODE (op) == PLUS\n> /* Omit testing REG_P (XEXP (op, 0)). */\n> && REG_P (XEXP (op, 1)))\")\n> (match_operand 0 \"address_operand\")))\n> \n> which doesn't accept offsettable addresses. At this point I'm not\n> entirely sure what the contract between targets and LRA is. My reading\n> so far was that due to goal_alt_offmemok[i] it is safe to use\n> offsettable addresses.\n\ngoal_alt_offmemok[i] is derived from offmemok which is computed in\nprocess_alt_operands() as e.g. here:\n\n case CT_MEMORY:\n case CT_RELAXED_MEMORY:\n if (MEM_P (op)\n && satisfies_memory_constraint_p (op, cn))\n win = true;\n else if (spilled_pseudo_p (op))\n win = true;\n\n /* If we didn't already win, we can reload constants\n via force_const_mem or put the pseudo value into\n memory, or make other memory by reloading the\n address like for 'o'. */\n if (CONST_POOL_OK_P (mode, op)\n || MEM_P (op) || REG_P (op)\n /* We can restore the equiv insn by a\n reload. */\n || equiv_substition_p[nop])\n badop = false;\n constmemok = true;\n offmemok = true;\n break;\n\nHere offmemok is set without explicitly checking whether the constraint\naccepts offsettable memory or not. So far this was no problem because\ninside of\n\n if (goal_alt_matched[i][0] == -1 && goal_alt_offmemok[i] && MEM_P (op))\n\nevery resulting address was a single register. I'm a bit puzzled.\nEither goal_alt_offmemok[i] doesn't mean that offsettable addresses are\nok, or another check is required before setting offmemok to true. Any\nthoughts?\n\nCheers,\nStefan\n\n\n> \n> > \n> > LRA reuses the reload pseudo generated for one insn (please see usage of\n> > curr_insn_input_reloads).  The problem in not reusing reload pseudo for the\n> > above example is that because reload for anchor occurs from different\n> > insns.  First LRA reloads [*.LANCHOR0] (insn 17 generated to satisfy reg\n> > constraint in insn 12), then the anchor (from insn 17 ), and then reload\n> > *.LANCHOR0 from 2nd op of insn 12.  But I'd not be worry that the reload\n> > pseudos get different hard regs.  Knowing how assigning hard regs works in\n> > LRA I see very small probability that the pseduos get different regs.\n> > \n> > BTW I did not reproduce the testcase situation w/o -march options (the\n> > anchor in this case already in a pseudo before RA).  But -march=z13\n> > reproduces it.  So probably you need to add this option to the test.\n> \n> Ahh right, I tested this patch on top of a private one where the test\n> case is successful for many archs. Currently it is failing because\n> the last alternative of insn cmpdi_cct is rejected for vanilla and\n> accepted for my private patch. It will take me some time to polish up\n> the private patch. Thus, I think we have two options here. Proceed\n> with this patch without a test case, or wait until the other patch is\n> ready. I'm fine either way.\n> \n> I was afraid of a flaky test and deliberately chose this test since it\n> guarantees that the section anchor ends up in the very same reload\n> register. Maybe I should be more brave here ;-)\n> \n> Thanks,\n> Stefan\n> \n> > \n> > So the patch (with -march=z13 or other one reproducing the situation as\n> > additional option for the test) is ok for me. Thank you.\n> > \n> > > ---\n> > > gcc/lra-constraints.cc | 30 +++++++++++++++++++\n> > > .../gcc.target/s390/section-anchors-4.c | 25 ++++++++++++++++\n> > > 2 files changed, 55 insertions(+)\n> > > create mode 100644 gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > > \n> > > diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc\n> > > index ccd68efc956..6779dfee020 100644\n> > > --- a/gcc/lra-constraints.cc\n> > > +++ b/gcc/lra-constraints.cc\n> > > @@ -4839,6 +4839,36 @@ curr_insn_transform (bool check_only_p)\n> > > \t new_reg = emit_inc (rclass, *loc,\n> > > \t\t\t\t/* This value does not matter for MODIFY. */\n> > > \t\t\t\tGET_MODE_SIZE (GET_MODE (op)));\n> > > +\t /* Try to pull out section anchors. For example, instead of\n> > > +\t reloading an \"entire\" address like .LANCHOR42+offset only reload\n> > > +\t .LANCHOR42 and use the new reload register as the base register.\n> > > +\t This allows following optimizations to share section anchors and\n> > > +\t remove redundant loads. */\n> > > +\t else if (GET_CODE (*loc) == CONST\n> > > +\t\t && GET_CODE (XEXP (*loc, 0)) == PLUS\n> > > +\t\t && GET_CODE (XEXP (XEXP (*loc, 0), 0)) == SYMBOL_REF\n> > > +\t\t && SYMBOL_REF_ANCHOR_P (XEXP (XEXP (*loc, 0), 0))\n> > > +\t\t && CONST_INT_P (XEXP (XEXP (*loc, 0), 1))\n> > > +\t\t /* Some offsets are valid in conjunction with a symbol and\n> > > +\t\t invalid in conjunction with a register. Thus, pull out\n> > > +\t\t the anchor only in case the offset is a valid anchor\n> > > +\t\t offset. */\n> > > +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> > > +\t\t >= targetm.min_anchor_offset\n> > > +\t\t && INTVAL (XEXP (XEXP (*loc, 0), 1))\n> > > +\t\t <= targetm.max_anchor_offset)\n> > > +\t {\n> > > +\t rtx anchor = XEXP (XEXP (*loc, 0), 0);\n> > > +\t rtx offset = XEXP (XEXP (*loc, 0), 1);\n> > > +\n> > > +\t if (get_reload_reg (OP_IN, Pmode, anchor, rclass,\n> > > +\t\t\t\t NULL, false, false,\n> > > +\t\t\t\t \"offsetable address\", &new_reg))\n> > > +\t\t lra_emit_move (new_reg, anchor);\n> > > +\n> > > +\t\tnew_reg = gen_rtx_PLUS (Pmode, new_reg, offset);\n> > > +\t\tlra_assert (valid_address_p (Pmode, new_reg, MEM_ADDR_SPACE (op)));\n> > > +\t }\n> > > \t else if (get_reload_reg (OP_IN, Pmode, *loc, rclass,\n> > > \t\t\t\t NULL, false, false,\n> > > \t\t\t\t \"offsetable address\", &new_reg))\n> > > diff --git a/gcc/testsuite/gcc.target/s390/section-anchors-4.c b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > > new file mode 100644\n> > > index 00000000000..0b4cd081c61\n> > > --- /dev/null\n> > > +++ b/gcc/testsuite/gcc.target/s390/section-anchors-4.c\n> > > @@ -0,0 +1,25 @@\n> > > +/* { dg-do compile } */\n> > > +/* { dg-options \"-O2 -fdump-rtl-ira-slim -fdump-rtl-reload-slim\" } */\n> > > +/* { dg-final { scan-assembler-times \"\\tlarl\\t\" 1 } } */\n> > > +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[`\\\\\\*.LANCHOR0'\\\\\\],\\\\\\[const\\\\\\(`\\\\\\*.LANCHOR0'\\\\\\+0x8\\\\\\)\\\\\\]\\\\\\)\" \"ira\" } } */\n> > > +/* { dg-final { scan-rtl-dump \"%cc:CCZ=cmp\\\\\\(\\\\\\[(%r\\[1-9\\]\\[0-9\\]?):DI\\\\\\],\\\\\\[\\\\1:DI\\\\\\+0x8\\\\\\]\\\\\\)\" \"reload\" } } */\n> > > +\n> > > +/* Ensure that we get the same reload register for the second memory operand.\n> > > + Prior LRA we have\n> > > +\n> > > + 55: %cc:CCZ=cmp([`*.LANCHOR0'],[const(`*.LANCHOR0'+0x8)])\n> > > +\n> > > + and after LRA\n> > > +\n> > > + 59: %r1:DI=`*.LANCHOR0'\n> > > + 55: %cc:CCZ=cmp([%r1:DI],[%r1:DI+0x8]) */\n> > > +\n> > > +long x, y;\n> > > +\n> > > +long\n> > > +foo (void)\n> > > +{\n> > > + if (x == y)\n> > > + return 42;\n> > > + return 0;\n> > > +}\n> >","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=ZfxLOl+0;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=ZfxLOl+0","sourceware.org;\n dmarc=none (p=none dis=none) header.from=linux.ibm.com","sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com","sourceware.org; arc=none smtp.remote-ip=148.163.156.1"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gFyPF16srz1yKH\n\tfor ; Thu, 14 May 2026 01:41:15 +1000 (AEST)","from vm01.sourceware.org (localhost [IPv6:::1])\n\tby sourceware.org (Postfix) with ESMTP id C0C754BBC0A8\n\tfor ; Wed, 13 May 2026 15:41:13 +0000 (GMT)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n by sourceware.org (Postfix) with ESMTPS id BB02A4BBC0D1\n for ; Wed, 13 May 2026 15:40:00 +0000 (GMT)","from pps.filterd (m0356517.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 64D42j2o2611898; Wed, 13 May 2026 15:39:59 GMT","from ppma22.wdc07v.mail.ibm.com\n (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4e3nve0f7r-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Wed, 13 May 2026 15:39:59 +0000 (GMT)","from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])\n by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id\n 64DFdaal032078;\n Wed, 13 May 2026 15:39:58 GMT","from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])\n by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4e3nfh0egs-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Wed, 13 May 2026 15:39:57 +0000 (GMT)","from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com\n [10.20.54.104])\n by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 64DFdumj23069134\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Wed, 13 May 2026 15:39:56 GMT","from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 075B720043;\n Wed, 13 May 2026 15:39:56 +0000 (GMT)","from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id DBAAC20040;\n Wed, 13 May 2026 15:39:55 +0000 (GMT)","from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown\n [9.52.214.147])\n by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;\n Wed, 13 May 2026 15:39:55 +0000 (GMT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org C0C754BBC0A8","OpenDKIM Filter v2.11.0 sourceware.org BB02A4BBC0D1"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org BB02A4BBC0D1","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org BB02A4BBC0D1","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778686800; cv=none;\n b=sq9XTbvKlzGPw0soJvc/Y45fNKYffPGM1DA/om4WMOzdvSjQpcwSPXzAkF5yCAmeWaJopsn8RBaUGK9G24bpygZ4makvJBjK4ufxhxvuIHkfnx3AhH0d1xHXFLCgfBs5NyNLhKvYPYgfDGZu8FOgqlWRs+SoTSOwPeejJns0hHA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1778686800; c=relaxed/simple;\n bh=X2DwO52rw+8qRDbHT6Y6KEa1iC/a/8in5xSH9rbB9a0=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=hDkaz9e0o8cnFxvpP/ap6e+isYxK7GmEp8ouB12W56ZFd1v1eB7IFPrL1kvDdfIx8qaod6SK9LM2z6D7Btf9DcOCgGy4bkt6PXZjnkBtg1OdwlBH/jwF4xr7APZU1CnyzpNseIgJGXfwIPMNAqG3xs1xuD4Ec8SmsJ2KB7wcWig=","ARC-Authentication-Results":"i=1; sourceware.org;\n dkim=pass (2048-bit key, unprotected)\n header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1\n header.b=ZfxLOl+0","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n :content-transfer-encoding:content-type:date:from:in-reply-to\n :message-id:mime-version:references:subject:to; s=pp1; bh=q6PNFP\n RHIa4WgjfLjo0Xq3e0S4EgrJFERxXZEk92gYc=; b=ZfxLOl+0J3vhuq1YYkGV6s\n 9iVdkpoxyLTtJq++wTpPQFv+fMIhRH36gX6fu7AjQsMwOPTZNv4u+8qC9sqpRtaf\n 5ajXEtgZt3kTnqxHtRKvLC7gwbIMwC01ZAiZkd5Ok49URswcfklrnm0F6XNx5d3b\n fIuUaqeuN53SNZeFSmTcIthdUeiR4yX3Do/nApLGf1Zq7SvBemXDzW5ti6VfmYNl\n pT2M0HJfJb+x/fq+fzgClQ8Fc+XZYK/FdJ6WczJgAKvQM6Icd6eqvCzD/pPX8O5X\n OQzIdWmIQr4whmT7MJjobakpRI5Hj3/dV79GSndfKSCOvbV5nBDVP/mXB58gjLgw\n ==","Date":"Wed, 13 May 2026 17:39:55 +0200","From":"Stefan Schulze Frielinghaus ","To":"Vladimir Makarov ","Cc":"gcc-patches@gcc.gnu.org","Subject":"Re: [PATCH] lra: Reloading section anchors","Message-ID":"","References":"<20260506092124.2542192-1-stefansf@linux.ibm.com>\n <79d2f9d2-1647-4167-af49-7ea497feefc9@redhat.com>\n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n ","X-TM-AS-GCONF":"00","X-Authority-Analysis":"v=2.4 cv=Y/XIdBeN c=1 sm=1 tr=0 ts=6a049b4f cx=c_pps\n a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17\n a=8nJEP1OIZ-IA:10 a=NGcC8JguVDcA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=mDV3o1hIAAAA:8\n a=lI4cdwP1qJOU_4sc-bwA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10","X-Proofpoint-GUID":"VgURPZM8QM241xl2py9w7abl9MgTS6rl","X-Proofpoint-ORIG-GUID":"VgURPZM8QM241xl2py9w7abl9MgTS6rl","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNTEzMDE2MCBTYWx0ZWRfXybxtryGdwELh\n o/xkJRifPzNpGsJ+FZaoUb/qG9lHqx9enP1Gt4+JfODxlnpnw1KLu7v98gGZTYe0fLLjM43/cuP\n KaFypz9squavJ0U4MZUbHTeaDMdTfxHsJ30tcwrfNaxX2Rkd7h/ytZ1tHf+NnnGhH23fwqFbJv2\n JL2WsPPdgf0qk664hJ/v73zpsx6lmofD/n4zbI7XLtPHZPHCxk5ZC+SJGNv5LoyaaV+i6sLaSVn\n W1i2CpU76tW5zPTq3TGODfWjRs/5L2+PUHSFlN9m2FPQVmlX3CDdNlkjs6NJJwm8bC1aHzj3jg6\n gCn1tLgqOscwoxd2ylBZlXKq4+YSvgj6Sn6aRX6CCNBKVOf1u2kqoP0gdM6IEhTRpWl4f0fMKTg\n n3oy5DZTnOCJgfBiDnlkdaX2kCiISfyrj8JToWjedmmUIH58B0AMpcycFxkPkrvqndEzcSAUjpi\n 9l9nN9EXjvZF/z58JRA==","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-05-13_01,2026-05-13_01,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n clxscore=1015 priorityscore=1501 lowpriorityscore=0 phishscore=0\n malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 adultscore=0\n impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc=\n route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605050000\n definitions=main-2605130160","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]