[{"id":3676232,"web_url":"http://patchwork.ozlabs.org/comment/3676232/","msgid":"<CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>","list_archive_url":null,"date":"2026-04-12T04:29:10","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n>\n> On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> >\n> > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> >\n...\n> > >\n> > > Revert changes in ix86_find_max_used_stack_alignment\n> > >\n> > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > >\n> > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > isn't available,\n> > >\n> > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > local variable reference.\n> > >\n> > > Update the maximum stack slot alignment from memory alignment only if its\n> > > base may point to stack or frame pointers.\n> > >\n> > > The compile times of PR target/124165 and PR target/124684 test are\n> > > unchanged.\n> > >\n> > > PR target/109780\n> > > PR target/109093\n> > > PR target/123210\n> > > PR target/124098\n> > > PR target/124165\n> > > PR target/124684\n> > > PR target/124759\n> > > PR target/124789\n> > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > (find_base_term): Remove static.\n> > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > init_alias_analysis and end_alias_analysis.\n> > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > (find_base_term): New prototype.\n> >\n> > Please put the find_base_term declaration into alias.h given the\n> > implementation is in alias.cc\n>\n> Done.\n>\n> > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> >  {\n> > ...\n> >   /* Check RTL points-to info.  */\n> >   rtx base = find_base_term (XEXP (op, 0));\n> >   if (!base)\n> > ...\n> >\n> > I think it's better to use RTL points-to like the rest - as\n> > positive early out.  Thus\n> >\n> >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> >   rtx base = find_base_term (XEXP (op, 0));\n> >   if (base\n> >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> >     return;\n>\n> I changed it to\n>\n>   rtx base = find_base_term (XEXP (op, 0));\n>   if (base)\n>     {\n>       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n>       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n>           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n>         alignment = mem_align;\n>       return;\n>     }\n>\n> > and then continue with the code you have in if (!base) unconditionally,\n> > rewriting\n> >\n> >               /* Handle the case that OP is a stack memory operand in\n> >\n> >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > <char[1:80]> [(void *)&k]+0 S16 A128])\n> >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > *)&k] ] [116]))\n> >\n> >                  from gcc.target/i386/pr109093-1.c.  */\n> >               rtx x = DECL_RTL (var);\n> >               if (MEM_P (x))\n> >                 base = find_base_term (XEXP (x, 0));\n> >\n> > to be the same \"positive\" check.  But then I think the above\n> > case might be done entirely on decl devel by using\n> >\n> >     if (auto_var_in_fn (var, current_function_decl))\n> >       return;\n> >\n> > no need to dispatch through DECL_RTL?\n>\n> I changed it to\n>\n>      else if (decl_in_symtab_p (var))\n>         return;\n>\n> > and the end of the function should have the conservative fallback:\n> >\n> >   alignment = mem_align;\n> > }\n> >\n> > Thanks,\n> > Richard.\n> >\n> > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > (ix86_find_all_reg_uses_1): Likewise.\n> > > (ix86_find_all_reg_uses): Likewise.\n> > > (ix86_access_stack_p): Likewise.\n> > > (ix86_need_alignment_p_2): Likewise.\n> > > (ix86_need_alignment_p_1): Likewise.\n> > > (ix86_need_alignment_p): Likewise.\n> > > (ix86_update_stack_alignment_2): New function.\n> > > (ix86_update_stack_alignment_1): Likewise.\n> > > (ix86_update_stack_alignment): Rewrite.\n> > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > true, call ix86_update_stack_alignment on each INSN.\n> > >\n> > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > >\n> > >\n> >\n> Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> with find_base_term and static_reg_base_value.  If RTL points-to info\n> isn't available,\n>\n> 1. Use ix86_decompose_address to check for symbolic displacement.\n> 2. Check MEM_EXPR for stack argument reference, memory reference and\n> static/external variable reference.\n>\n> Update the maximum stack slot alignment from memory alignment only if its\n> base may point to stack or frame pointers.\n>\n> The compile times of PR target/124165 and PR target/124684 test are\n> unchanged.\n>\n> PR target/109780\n> PR target/109093\n> PR target/123210\n> PR target/124098\n> PR target/124165\n> PR target/124684\n> PR target/124759\n> PR target/124789\n> * alias.cc (static_reg_base_value): Moved to rtl.h.\n> (find_base_term): Remove static.\n> * function.cc (thread_prologue_and_epilogue_insns): Call\n> init_alias_analysis and end_alias_analysis.\n> * rtl.h (static_reg_base_value): Moved from alias.cc.\n> * alias.h (find_base_term): New prototype.\n> * config/i386/i386.cc (stack_access_data): Removed.\n> (ix86_find_all_reg_uses_1): Likewise.\n> (ix86_find_all_reg_uses): Likewise.\n> (ix86_access_stack_p): Likewise.\n> (ix86_need_alignment_p_2): Likewise.\n> (ix86_need_alignment_p_1): Likewise.\n> (ix86_need_alignment_p): Likewise.\n> (ix86_update_stack_alignment_2): New function.\n> (ix86_update_stack_alignment_1): Likewise.\n> (ix86_update_stack_alignment): Rewrite.\n> (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> true, call ix86_update_stack_alignment on each INSN.\n>\n> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> Co-Authored-By: Richard Biener <rguenther@suse.de>\n>\n> --\n> H.J.\n\nSome updates:\n\n1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n2.  Use\n\n      if (TREE_CODE (var) == PARM_DECL\n          || TREE_CODE (var) == MEM_REF\n          || TREE_CODE (var) == TARGET_MEM_REF\n          || decl_in_symtab_p (var))\n        return;","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=M1RPx4wS;\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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=M1RPx4wS","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.216.47"],"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 4ftcz65Pdrz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 14:30:25 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 2CAC64BA2E20\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 04:30:23 +0000 (GMT)","from mail-pj1-f47.google.com (mail-pj1-f47.google.com\n [209.85.216.47])\n by sourceware.org (Postfix) with ESMTPS id 6D6844BA2E18\n for <gcc-patches@gcc.gnu.org>; Sun, 12 Apr 2026 04:29:51 +0000 (GMT)","by mail-pj1-f47.google.com with SMTP id\n 98e67ed59e1d1-35f9ab079bdso96742a91.2\n for <gcc-patches@gcc.gnu.org>; Sat, 11 Apr 2026 21:29:51 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 2CAC64BA2E20","OpenDKIM Filter v2.11.0 sourceware.org 6D6844BA2E18"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 6D6844BA2E18","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 6D6844BA2E18","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1775968191; cv=pass;\n b=FACYMMogc8N4y0JPaLT74SfjRUwlEWqdEtDfdReubL6VuiOxB8MX2CKARbVUQvJQ6/eANdJixO4P5JHXqiAt8pTPef0vw7ZN1XIfNx9vOqKHIC25GulJioLmi03wdTCf22N++pEYU7v6LcF7VLAtem1mOXfElnbpM9A3mAK/u88=","i=1; a=rsa-sha256; t=1775968190; cv=none;\n d=google.com; s=arc-20240605;\n b=cA6HPQO2yYueK8+rBlf5eWPELJECU31uiDsDgmYc6uMeWIFzCLrZVdUpPnF/XpyYO1\n xVyrZHAo+MJvHs9Pe89YUhZ8tuCUoVoFausPW70bdTfYjjcTUCjgqZ9KB3rIPGertI05\n l3BDQANIYMm5FiSqmeN882ht1RfYwpg09jq8doHiHZUmJO3UWGjFqBd7QS1/KCKduUNY\n xGStse3WUyeRW1mhG7FAClEwkc+Yxz+Rn5hmNoBrUYbEabp+aVP13Lk17LvhMHtHAJ3h\n 86kWyPc0q69d9nXRza5m6UEPkFXzH1ok43i9POgSJrJ4nOg+50CNN4yCtb9Viabh8hM3\n 7wNQ=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1775968191; c=relaxed/simple;\n bh=GcXUTc67r7exk0GMzimly0cSMANLH4uz6+I3/W+k/4o=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=Bl1MXoBC1ZktRHAHwIh9DVxnpTnAYM2f/9438PlZvPJkYJuFafuCN7FRKqwjUPpnk2S3ADkRTF2yPxBR1jqajfvIB8WOOX+P3i1SpfQyc58h5aqSSf+XuCF69J6t/0HxwkG9I8HZcM9hw5t4SgF2x1nVBwozyi+InVc9rjB9xQc=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=wfj+ycr/5nQbIfXXSOksJnkBFQI9K9c+sdHNcwZ4KhY=;\n fh=sFFq4wvy7UcSKlgT6RiqXOQFQjorSTnVHLzf7/o8kz4=;\n b=h4ZWRlL/ka9aFwI15NzpptWJIIvt3uRoTyRGkI4UAf1aGGALu2PJM6QtyiyKfZm+PJ\n btrNw9x7LEaeUlFUXCDr7O+C4Hv6Jik3rni/LRfi/TfMAQ8jBCXuqdtWKDsBIrrzfxwo\n kH+Up18UA0bvxaGYSBuZdW73hxwcSJRPRWgjPaggdKExqAd6jxliAwCWm4LllriTRHr7\n ZzIzZb+NXR5MfzdofYGA7oC2emeBZyMU9j2I74kDohNaufuU0Tc2byDSgLJmv0LC3iO5\n kctVA28eh5fsx7fxkndkEgOlNwDvxeX/VFm+iO5U/U9grPtjVsH/TchMqCVg6YjHLJTC\n +FKQ==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775968190; x=1776572990; darn=gcc.gnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=wfj+ycr/5nQbIfXXSOksJnkBFQI9K9c+sdHNcwZ4KhY=;\n b=M1RPx4wS/+85SP0W/2yTP1uz5DHcmkrp/zPat/DUiadmw+WvgpS1iBKRwrYgg2W2YW\n SVA5GiSDrPVLv9km1WV/9Zve1vqBh7yN4hk9paBjN6sK6/61G4DyxRLNjEhGQ6+BJJoL\n HuMixrtpvmrFcGHkvvvArYU/987koJe2chNZpQEGB0mPnRxDnmqvxHtnlAvB9iOY+aRA\n VcGbKyy2Yj+uno8AKHVnFyqmjWVpmUN9ez0vLrhmHIzA3KYT7vZk+SQOPUHHxdXId4Lp\n w19x7IXT0fwuD5YZVvl9jhDN77LsjSZ2KB60cuhM1LgtXhod6mc6vRN3lMkqj1pBQ/Ct\n zvEg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775968190; x=1776572990;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=wfj+ycr/5nQbIfXXSOksJnkBFQI9K9c+sdHNcwZ4KhY=;\n b=RBFGy6VGQRD0sYbe5rdd16zBAiTanY7DRjIoFeK/hrZQvhdv/zZMMQHM5KXFzTmBoR\n dkiWMt0PZ6BoC4MEjvYVKKlDHE2Xwg8uv+Lj4RAUoL+z9rdY7w3/TrW7KOJmF4Vex89O\n 7aryo6aWlktreAu8N1/YYt8dBLYvzr5EnFDbornTEb+OL6a9nk5P/FEHp3Ed+Rid6ZXJ\n Ym8fxebxLI64uVk0JQN8a5m0dt7Zr1fheYUfT0vXPoYTg6CxO3CVZrjjZN8Tm2UWwT+K\n kA+nVi0cy2UcttoPm3jGH/++sFZ9+GMTrqZS/sVjcGkIiCZdA9+I7oyTWB2Mj1X8I+rQ\n 84gg==","X-Gm-Message-State":"AOJu0YxSvHAsjBxLRBUp1V5HdExVc7gL0QAAPUymUnZf3R9KVd1M053A\n k3SKgGy4s9vShhqm3mhBF8DlKBcJVdQqaDRtNJcGVQB0dxuCNEOAj0PM37Pd8LMn6a1UH/ij8d0\n 6VbVWOH1RrcaESS7GeOafzG2Z+uZJVO0=","X-Gm-Gg":"AeBDievlgvOoq0ljcfG2ZC8+41wh62Gff2PHfSEZrTybnMg7mCWXhJ7QEDSAe6fPRBd\n bz1FesH92Icm/hD0ZyOdKWQi+fQI5tkqhlz99KYKKO8IGbPBEGjDvD3if8QqkpafKohK4EA6WWl\n ytsAWP/BO6aG56Bj9OgQfw4c3yTWLtnfOPTayliLadCFWqIpacGU8fbDtod07VhzHcV5bVpxgZl\n 575ix5QX1NrEcYPzHFVfhIfl1Laet35CVzXIMJW0Q8fZ0/rO7y4kgas9wzooG5K9fPDGLKmafs1\n qmPJXlI=","X-Received":"by 2002:a17:90b:35d0:b0:35c:cba:344f with SMTP id\n 98e67ed59e1d1-35e42814b32mr8662172a91.13.1775968190111; Sat, 11 Apr 2026\n 21:29:50 -0700 (PDT)","MIME-Version":"1.0","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOp-EFNdwdahM9m3y-2GneOQ2BF2P6mhkkjgXUybQXb2XA@mail.gmail.com>\n <CAMe9rOpVU1ppyO=3UfTWS8dTnbhYWmSiP0_ZsvTwo9zv8EEkoQ@mail.gmail.com>\n <nn314941-07qo-54n3-4o6s-48rnpo5r3199@fhfr.qr>\n <CAMe9rOrVGwKbHdofQ9TqBAXYObL5Yu+J4ZnTeb5bD+pNve3zPw@mail.gmail.com>\n <0305rr41-n79q-q3po-222p-0p6468979827@fhfr.qr>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>","In-Reply-To":"\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>","From":"\"H.J. Lu\" <hjl.tools@gmail.com>","Date":"Sun, 12 Apr 2026 12:29:10 +0800","X-Gm-Features":"AQROBzCTJmckWYuGV4LfcdsyrxD5lIsKZVsUU6jYITA8qX1Djwxb7qnfVJRDjLA","Message-ID":"\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","To":"Richard Biener <rguenther@suse.de>","Cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Content-Type":"multipart/mixed; boundary=\"0000000000001abffe064f3bd1b6\"","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676546,"web_url":"http://patchwork.ozlabs.org/comment/3676546/","msgid":"<po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>","list_archive_url":null,"date":"2026-04-13T08:17:33","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Sun, 12 Apr 2026, H.J. Lu wrote:\n\n> On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> >\n> > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > >\n> > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > >\n> ...\n> > > >\n> > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > >\n> > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > >\n> > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > isn't available,\n> > > >\n> > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > local variable reference.\n> > > >\n> > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > base may point to stack or frame pointers.\n> > > >\n> > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > unchanged.\n> > > >\n> > > > PR target/109780\n> > > > PR target/109093\n> > > > PR target/123210\n> > > > PR target/124098\n> > > > PR target/124165\n> > > > PR target/124684\n> > > > PR target/124759\n> > > > PR target/124789\n> > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > (find_base_term): Remove static.\n> > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > init_alias_analysis and end_alias_analysis.\n> > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > (find_base_term): New prototype.\n> > >\n> > > Please put the find_base_term declaration into alias.h given the\n> > > implementation is in alias.cc\n> >\n> > Done.\n> >\n> > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > >  {\n> > > ...\n> > >   /* Check RTL points-to info.  */\n> > >   rtx base = find_base_term (XEXP (op, 0));\n> > >   if (!base)\n> > > ...\n> > >\n> > > I think it's better to use RTL points-to like the rest - as\n> > > positive early out.  Thus\n> > >\n> > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > >   rtx base = find_base_term (XEXP (op, 0));\n> > >   if (base\n> > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > >     return;\n> >\n> > I changed it to\n> >\n> >   rtx base = find_base_term (XEXP (op, 0));\n> >   if (base)\n> >     {\n> >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> >         alignment = mem_align;\n> >       return;\n> >     }\n\nThat looks good.\n\n> > > and then continue with the code you have in if (!base) unconditionally,\n> > > rewriting\n> > >\n> > >               /* Handle the case that OP is a stack memory operand in\n> > >\n> > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > *)&k] ] [116]))\n> > >\n> > >                  from gcc.target/i386/pr109093-1.c.  */\n> > >               rtx x = DECL_RTL (var);\n> > >               if (MEM_P (x))\n> > >                 base = find_base_term (XEXP (x, 0));\n> > >\n> > > to be the same \"positive\" check.  But then I think the above\n> > > case might be done entirely on decl devel by using\n> > >\n> > >     if (auto_var_in_fn (var, current_function_decl))\n> > >       return;\n> > >\n> > > no need to dispatch through DECL_RTL?\n> >\n> > I changed it to\n> >\n> >      else if (decl_in_symtab_p (var))\n> >         return;\n> >\n> > > and the end of the function should have the conservative fallback:\n> > >\n> > >   alignment = mem_align;\n> > > }\n> > >\n> > > Thanks,\n> > > Richard.\n> > >\n> > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > (ix86_find_all_reg_uses): Likewise.\n> > > > (ix86_access_stack_p): Likewise.\n> > > > (ix86_need_alignment_p_2): Likewise.\n> > > > (ix86_need_alignment_p_1): Likewise.\n> > > > (ix86_need_alignment_p): Likewise.\n> > > > (ix86_update_stack_alignment_2): New function.\n> > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > (ix86_update_stack_alignment): Rewrite.\n> > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > true, call ix86_update_stack_alignment on each INSN.\n> > > >\n> > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > >\n> > > >\n> > >\n> > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > isn't available,\n> >\n> > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > static/external variable reference.\n> >\n> > Update the maximum stack slot alignment from memory alignment only if its\n> > base may point to stack or frame pointers.\n> >\n> > The compile times of PR target/124165 and PR target/124684 test are\n> > unchanged.\n> >\n> > PR target/109780\n> > PR target/109093\n> > PR target/123210\n> > PR target/124098\n> > PR target/124165\n> > PR target/124684\n> > PR target/124759\n> > PR target/124789\n> > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > (find_base_term): Remove static.\n> > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > init_alias_analysis and end_alias_analysis.\n> > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > * alias.h (find_base_term): New prototype.\n> > * config/i386/i386.cc (stack_access_data): Removed.\n> > (ix86_find_all_reg_uses_1): Likewise.\n> > (ix86_find_all_reg_uses): Likewise.\n> > (ix86_access_stack_p): Likewise.\n> > (ix86_need_alignment_p_2): Likewise.\n> > (ix86_need_alignment_p_1): Likewise.\n> > (ix86_need_alignment_p): Likewise.\n> > (ix86_update_stack_alignment_2): New function.\n> > (ix86_update_stack_alignment_1): Likewise.\n> > (ix86_update_stack_alignment): Rewrite.\n> > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > true, call ix86_update_stack_alignment on each INSN.\n> >\n> > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> >\n> > --\n> > H.J.\n> \n> Some updates:\n> \n> 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> 2.  Use\n> \n>       if (TREE_CODE (var) == PARM_DECL\n>           || TREE_CODE (var) == MEM_REF\n>           || TREE_CODE (var) == TARGET_MEM_REF\n>           || decl_in_symtab_p (var))\n>         return;\n\nSkipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\nneither is skipping for PARM_DECL since that will also hit on\ncallee copies with larger alignment.\n\n   if (VAR_P (var) && decl_in_symtab_p (var))\n     return;\n\nor\n\n   if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n     return;\n\nwould be both OK (I think the latter is more to the point).\n\nThe PARM_DECL case should be catched by find_base_term which\nshould return static_reg_base_value[ARG_POINTER_REGNUM] for them\n(but not for the callee copy which should be based on\nFRAME_POINTER_REGNUM).\n\nThe address-space case chould be handled generally at the toplevel,\n\n  /* All stack is in the generic address space.  */\n  if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n    return;\n\n         (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM \n<vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n              (reg:V4DI 20 xmm0 [117]))\n\n         from gcc.target/i386/pr124098.c,\n\nI don't see how to easily handle this case.  GIMPLE points-to\ninfo (which would be accessible through _34) does currently not\ntrack a separate \"may point to (local) stack\" - that would be\nstraight-forward to add though (but it increasingly feels like\nsomething to do for stage1).\n\n\n         (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i * \n{ref-all})s_1(D) & 4294967280B] ] [103])\n              (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i * \n{ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n\n         from gcc.target/i386/pr53907.c and\n\nthis shows a s_1(D) based address (huh, the & is unexpected there),\nwhich means it's likely an incoming parameter.  I would have expected\nthat RTL PTA analysis would assign it some class, but it's\npretty weak PTA.  Matching it explicitly with\n\nif (TREE_CODE (var) == MEM_REF\n    || TREE_CODE (var) == TARGET_MEM_REF)\n  {\n    tree ptr = TREE_OPERAND (var, 0);\n    if (TREE_CODE (ptr) == BIT_AND_EXPR)\n      ptr = TREE_OPERAND (ptr, 0);\n    /* An access based on an incoming pointer cannot point to\n       local stack.  */\n    if (TREE_CODE (ptr) == SSA_NAME\n        && SSA_NAME_IS_DEFAULT_DEF (ptr)\n        && TREE_CODE (SSA_NAME_VAR (ptr)) == PARM_DECL)\n      return;\n  }\n\nwould be possible, but similar to the above case GIMPLE level PTA\ncould track this as does-not-point-to-local-stack.\n\nRichard.","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=d30dIcCK;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=Qe/h0m2P;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=wN3kVtHt;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=Xey3n+O5;\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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=d30dIcCK;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=Qe/h0m2P;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=wN3kVtHt;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=Xey3n+O5","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.131","smtp-out2.suse.de;\n\tnone"],"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 4fvKzN0kDlz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 18:18:06 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id D5FD54BA2E29\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 08:18:04 +0000 (GMT)","from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])\n by sourceware.org (Postfix) with ESMTPS id 202354BA2E09\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 08:17:35 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out2.suse.de (Postfix) with ESMTPS id C2C495BD1F;\n Mon, 13 Apr 2026 08:17:33 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org D5FD54BA2E29","OpenDKIM Filter v2.11.0 sourceware.org 202354BA2E09"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 202354BA2E09","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 202354BA2E09","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776068255; cv=none;\n b=iq2Ldhxo1rtvmxx263yzRpHKsm1v2ygHyfKuNleXU7BSwclkDMptIUWHjjwQu5H2yN2ZJgPM+avuEcWHaxQ1YHF96u5cSAMjZywl5DsUxH7s1j2E9+X9C47j9u1WbbkKJkUyH1Hzde2djyhDSiibeyqolhx0z1WOp38OhKrdtb0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776068255; c=relaxed/simple;\n bh=chJEM2VEg0V0ewQqAbM7wsrE8FvH6bU76Qhdee/dOfI=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=UqVVmlGqHgqxHBept+Mm7sKQYpTPh5XcwMgrzl04DPgpS6dVjlfXzR9gMWtZN3KhbcdrnUeW9P2ZcUVcPR2ZdvJgCpM2vMCEEN4bCiFq3PiLRnz1XNUWlneTwvmlMISgvbsX01Xh8N4v0C6dN1CZntEfrBgRayi3XWglVMeFwA8=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776068254;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=QGTOpkQD3IeJ0O9hrglGZrL5kLlG0iBHNfczu3kSApM=;\n b=d30dIcCKNt9ss/NnB3Mm3V+XnHilszIcr5AmgYAPNMypZgu87za1/BR8L9HD456MUcQw1z\n QKs4ADAI5tE+w7qj9zM9TvX4i6EWxkywD4QyGeqVIQQdKkLhrsMvqvgkzBzd9OrYfktYsT\n 7OlKXC5QGP8Js4UkfFSsiT1I+HCaJQI=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776068254;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=QGTOpkQD3IeJ0O9hrglGZrL5kLlG0iBHNfczu3kSApM=;\n b=Qe/h0m2PgZtvANHlWaAXYhAxYuWdlSawomNpf3pexCGT8nY/IZDTHxZxGra8TPNYfcpVRC\n uJs1dByWLheLrUBA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776068253;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=QGTOpkQD3IeJ0O9hrglGZrL5kLlG0iBHNfczu3kSApM=;\n b=wN3kVtHtXNTGbbMgBizyJOMeY6PdMnGS4gsTKCsv5DNTqTm4jlxCDbb4onlcHkcqlB+Dec\n vG4vnZaNt8FBumh1C1hGocmOBVlknC0TkBvrPUe9t7KfXSf3bsDQXHyEKiKZ4YctNfKeaf\n hthAa2Oc+x4r2YB7CSTzV5cIpA3Av6o=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776068253;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=QGTOpkQD3IeJ0O9hrglGZrL5kLlG0iBHNfczu3kSApM=;\n b=Xey3n+O5jvnL4tFH8jIRGsMId/6chx/89Q57zDUfzu5x0xwhdzyStd26iBCSTcx6zTEuPl\n F8ZAC5E8CYfUQMAA=="],"Date":"Mon, 13 Apr 2026 10:17:33 +0200 (CEST)","From":"Richard Biener <rguenther@suse.de>","To":"\"H.J. Lu\" <hjl.tools@gmail.com>","cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","In-Reply-To":"\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>","Message-ID":"<po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOrVGwKbHdofQ9TqBAXYObL5Yu+J4ZnTeb5bD+pNve3zPw@mail.gmail.com>\n <0305rr41-n79q-q3po-222p-0p6468979827@fhfr.qr>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/mixed;\n boundary=\"-1475677436-1996936400-1776068253=:28865\"","X-Spamd-Result":"default: False [-1.80 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n SUSPICIOUS_RECIPS(1.50)[]; CTYPE_MIXED_BOGUS(1.00)[];\n NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000];\n MIME_GOOD(-0.10)[multipart/mixed,text/plain];\n URIBL_BLOCKED(0.00)[suse.de:email,murzim.nue2.suse.org:helo,alias.cc:url,gcc.target:url,fhfr.qr:mid,function.cc:url];\n TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com];\n FUZZY_RATELIMITED(0.00)[rspamd.com];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n MIME_TRACE(0.00)[0:+,1:+]; ARC_NA(0.00)[];\n TO_MATCH_ENVRCPT_ALL(0.00)[];\n FREEMAIL_ENVRCPT(0.00)[gmail.com];\n FREEMAIL_CC(0.00)[gcc.gnu.org,gmail.com,intel.com,gentoo.org,googlemail.com];\n FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[];\n RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_ZERO(0.00)[0];\n MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676567,"web_url":"http://patchwork.ozlabs.org/comment/3676567/","msgid":"<CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>","list_archive_url":null,"date":"2026-04-13T08:53:15","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n>\n> On Sun, 12 Apr 2026, H.J. Lu wrote:\n>\n> > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > >\n> > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > >\n> > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > >\n> > ...\n> > > > >\n> > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > >\n> > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > >\n> > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > isn't available,\n> > > > >\n> > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > local variable reference.\n> > > > >\n> > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > base may point to stack or frame pointers.\n> > > > >\n> > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > unchanged.\n> > > > >\n> > > > > PR target/109780\n> > > > > PR target/109093\n> > > > > PR target/123210\n> > > > > PR target/124098\n> > > > > PR target/124165\n> > > > > PR target/124684\n> > > > > PR target/124759\n> > > > > PR target/124789\n> > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > (find_base_term): Remove static.\n> > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > init_alias_analysis and end_alias_analysis.\n> > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > (find_base_term): New prototype.\n> > > >\n> > > > Please put the find_base_term declaration into alias.h given the\n> > > > implementation is in alias.cc\n> > >\n> > > Done.\n> > >\n> > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > >  {\n> > > > ...\n> > > >   /* Check RTL points-to info.  */\n> > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > >   if (!base)\n> > > > ...\n> > > >\n> > > > I think it's better to use RTL points-to like the rest - as\n> > > > positive early out.  Thus\n> > > >\n> > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > >   if (base\n> > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > >     return;\n> > >\n> > > I changed it to\n> > >\n> > >   rtx base = find_base_term (XEXP (op, 0));\n> > >   if (base)\n> > >     {\n> > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > >         alignment = mem_align;\n> > >       return;\n> > >     }\n>\n> That looks good.\n>\n> > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > rewriting\n> > > >\n> > > >               /* Handle the case that OP is a stack memory operand in\n> > > >\n> > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > *)&k] ] [116]))\n> > > >\n> > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > >               rtx x = DECL_RTL (var);\n> > > >               if (MEM_P (x))\n> > > >                 base = find_base_term (XEXP (x, 0));\n> > > >\n> > > > to be the same \"positive\" check.  But then I think the above\n> > > > case might be done entirely on decl devel by using\n> > > >\n> > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > >       return;\n> > > >\n> > > > no need to dispatch through DECL_RTL?\n> > >\n> > > I changed it to\n> > >\n> > >      else if (decl_in_symtab_p (var))\n> > >         return;\n> > >\n> > > > and the end of the function should have the conservative fallback:\n> > > >\n> > > >   alignment = mem_align;\n> > > > }\n> > > >\n> > > > Thanks,\n> > > > Richard.\n> > > >\n> > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > (ix86_access_stack_p): Likewise.\n> > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > (ix86_need_alignment_p): Likewise.\n> > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > >\n> > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > >\n> > > > >\n> > > >\n> > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > isn't available,\n> > >\n> > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > static/external variable reference.\n> > >\n> > > Update the maximum stack slot alignment from memory alignment only if its\n> > > base may point to stack or frame pointers.\n> > >\n> > > The compile times of PR target/124165 and PR target/124684 test are\n> > > unchanged.\n> > >\n> > > PR target/109780\n> > > PR target/109093\n> > > PR target/123210\n> > > PR target/124098\n> > > PR target/124165\n> > > PR target/124684\n> > > PR target/124759\n> > > PR target/124789\n> > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > (find_base_term): Remove static.\n> > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > init_alias_analysis and end_alias_analysis.\n> > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > * alias.h (find_base_term): New prototype.\n> > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > (ix86_find_all_reg_uses_1): Likewise.\n> > > (ix86_find_all_reg_uses): Likewise.\n> > > (ix86_access_stack_p): Likewise.\n> > > (ix86_need_alignment_p_2): Likewise.\n> > > (ix86_need_alignment_p_1): Likewise.\n> > > (ix86_need_alignment_p): Likewise.\n> > > (ix86_update_stack_alignment_2): New function.\n> > > (ix86_update_stack_alignment_1): Likewise.\n> > > (ix86_update_stack_alignment): Rewrite.\n> > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > true, call ix86_update_stack_alignment on each INSN.\n> > >\n> > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > >\n> > > --\n> > > H.J.\n> >\n> > Some updates:\n> >\n> > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > 2.  Use\n> >\n> >       if (TREE_CODE (var) == PARM_DECL\n> >           || TREE_CODE (var) == MEM_REF\n> >           || TREE_CODE (var) == TARGET_MEM_REF\n> >           || decl_in_symtab_p (var))\n> >         return;\n>\n> Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> neither is skipping for PARM_DECL since that will also hit on\n> callee copies with larger alignment.\n>\n>    if (VAR_P (var) && decl_in_symtab_p (var))\n>      return;\n>\n> or\n>\n>    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n>      return;\n>\n> would be both OK (I think the latter is more to the point).\n>\n> The PARM_DECL case should be catched by find_base_term which\n> should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> (but not for the callee copy which should be based on\n> FRAME_POINTER_REGNUM).\n>\n> The address-space case chould be handled generally at the toplevel,\n>\n>   /* All stack is in the generic address space.  */\n>   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n>     return;\n>\n>          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n>               (reg:V4DI 20 xmm0 [117]))\n>\n>          from gcc.target/i386/pr124098.c,\n>\n> I don't see how to easily handle this case.  GIMPLE points-to\n> info (which would be accessible through _34) does currently not\n> track a separate \"may point to (local) stack\" - that would be\n> straight-forward to add though (but it increasingly feels like\n> something to do for stage1).\n\nWhat should we do for  gcc.target/i386/pr124098.c in the meantime?\nxfail it?\n\n>\n>          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> {ref-all})s_1(D) & 4294967280B] ] [103])\n>               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n>\n>          from gcc.target/i386/pr53907.c and\n>\n> this shows a s_1(D) based address (huh, the & is unexpected there),\n> which means it's likely an incoming parameter.  I would have expected\n> that RTL PTA analysis would assign it some class, but it's\n> pretty weak PTA.  Matching it explicitly with\n>\n> if (TREE_CODE (var) == MEM_REF\n>     || TREE_CODE (var) == TARGET_MEM_REF)\n>   {\n>     tree ptr = TREE_OPERAND (var, 0);\n>     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n>       ptr = TREE_OPERAND (ptr, 0);\n>     /* An access based on an incoming pointer cannot point to\n>        local stack.  */\n>     if (TREE_CODE (ptr) == SSA_NAME\n>         && SSA_NAME_IS_DEFAULT_DEF (ptr)\n>         && TREE_CODE (SSA_NAME_VAR (ptr)) == PARM_DECL)\n>       return;\n>   }\n>\n> would be possible, but similar to the above case GIMPLE level PTA\n> could track this as does-not-point-to-local-stack.\n>\n> Richard.","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=WpEtFpGt;\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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=WpEtFpGt","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.214.169"],"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 4fvLnH2MCGz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 18:54:25 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 8CDB14BA2E2F\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 08:54:23 +0000 (GMT)","from mail-pl1-f169.google.com (mail-pl1-f169.google.com\n [209.85.214.169])\n by sourceware.org (Postfix) with ESMTPS id 6D7CC4BA2E20\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 08:53:53 +0000 (GMT)","by mail-pl1-f169.google.com with SMTP id\n d9443c01a7336-2b4650d5f5cso1317855ad.0\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 01:53:53 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 8CDB14BA2E2F","OpenDKIM Filter v2.11.0 sourceware.org 6D7CC4BA2E20"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 6D7CC4BA2E20","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 6D7CC4BA2E20","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776070433; cv=pass;\n b=JhvgHgf808K3bBpcZGk95kc+klqwZ1u/YrcqZX0diN+B87rzPnw+BRzhqIY4x8OmMhLRbNsQLuujCpH/DTXqGoxyx/kAlUQJinU/hnDoztd6bPEojsZa2Pr5HrXhYA5bfoVF5kJmM51EPlhnmyux1Ry4bYGObt5gkCpn1rLRT6w=","i=1; a=rsa-sha256; t=1776070432; cv=none;\n d=google.com; s=arc-20240605;\n b=D35cnVE9F86o5lNvZjIw36UJ4wXrhFoZ1apAZmy9BTv1jYJmZfigaBE9cXPw8mK7Be\n oez/kbcCUG4S3Q2p0WfpHvcNirIWvuJIy+GzQLgL10y5HpEl4UmOCdWPU73Yi4aPDdEp\n ZLWu8BA9Pr/27eD11+1EIr4s+rK9Xf/S4MMwve5MSk7yZRvnL8L+IG4JS0VDzzOXFZEc\n seb9C7JQBkP1i9GBFuGg2oMh5b/pWbuMzUGSSOM3sxGk3JZ+gatzdfLCcSGYEKfFM0kj\n B0BqtIiO2/fg3W5+Xl2vlRIAZv9pOyMbfO79JVVL/DaB6hdbNQJA5bzBilVOPXG/pgwl\n fvqw=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776070433; c=relaxed/simple;\n bh=0Qid7q1KP336xK6i0nheQHFu5kJSZkt9SGXCoa2XOV0=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=b+cwu0GBTWd0Uqm4dawBevNKo0k9FEIIZ/kc6NcgSawNfrSywXavxg9uYCHxVaVCC2eb/S62z8ciraFgNdUvGnA5+t+rQC0lCxRFJW8N/BvjPCv2n1ew8EAelDG3uSpa79ZDF8fa7DYgvQm1OOeETxyouNm5yeo8W3lwg6cbozA=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=j8M5iKl9EZ7TlT4hhGNWr/ZtRU/tzRT/ib2/yLH2uHM=;\n fh=sFFq4wvy7UcSKlgT6RiqXOQFQjorSTnVHLzf7/o8kz4=;\n b=lcwqImEgrd0wBu3Z9a/xTtocRGa0fpJFxI0j6OU0dZfNJkgPs/upt8kJI1d+XDPOkh\n ZEA1KGUfXNjGdMGTIaWkyzByY+NNVaCdV8Yi3mnd8Qcw9BJz9JPuc9dcYN+5Px5AIh6t\n GCQkOciV7RhxK6gYTzMVEk6G+eejRIBNEV0/jTKvjqCbotnoO20lqeFMIMZd/KmopIL7\n hvzokVRX7knuD4JoNKTgxRWMJLRsJIQ/yPW5asMpEsuCrU+03XdmHuKnzlv9aKcYd8Gb\n T9/0iOotzbfTo5loOY0r2F0nAWu5QgPfU5QKiLADAHJvSbMAy/CNrIS50x2C4/sA+LDC\n OlFA==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776070432; x=1776675232; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=j8M5iKl9EZ7TlT4hhGNWr/ZtRU/tzRT/ib2/yLH2uHM=;\n b=WpEtFpGtyykZ8NVfcwERXHRR5IwTQSeCgYOC/wxye5vrXZ/D4X8SYdRb2gqqHI3Bn6\n 4XWjQPxcbBnNhXpSxUqdHBT8RSW2eF2dZ0g2fvzIOOJKLs9ojBJkXruIznHSexyfBmm3\n wIn9dLlHn4Mz/kmcSRVx2nIze8mlGgAEe8TUhezAsjbjEX0d3rdOSOf23laXeG3kN1ek\n Jte2sXS9H1eRttfMq4pzN1EJ2qpx+gz8go8yrl03cpzALegYiMw0N9e1Nw2+05PiOKxP\n VAY+PuoFPBib/H4hppSAAx/uNRJvsM4QipPH2+CId9T3HA/0rE9zrd5eEV+4yLNstVlF\n jfZA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776070432; x=1776675232;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=j8M5iKl9EZ7TlT4hhGNWr/ZtRU/tzRT/ib2/yLH2uHM=;\n b=kv4HY5RngiLQvHDyZJTgLyncWV1hAEcFac51fuScXZ2wii5+sgp95bO/W0lYQHQ0sK\n Fa8ZPYOoFBQrax4d6kTyGMw/kIFYpjTgzuTiKxQLuhx0JfT9EeLDWbYF7Ppc++wZ9Zu+\n 2Dz1YC7vSNvr1IRRSvBp8rBjhCmarwb1JNG0G/I0dO9r4Np4KWh3ClSJlj1MtHbF3cmD\n bup3b7T2GS6G1Abhvd4s2ZJkKTUHsbImfZVtaDQxhWqt/5TMmu8IqaierrPJITqVd+IC\n C8H0U3M1pUT8AbklKpGAGvj7GStVPSehw1Iux+zjPNzNDf0nsBchjw4eGwvSr8kBcbdB\n 0KqA==","X-Gm-Message-State":"AOJu0Yyio1RKcJw/OWZDxgzg++KIqWHwWLNVKiIcXKQfuMT8uUaoNurn\n kfTqXy7OFMljmnhVU1qaHVRr6tovkhFd/Z7Bo/IUrnYf6yqWdMVmZ61hgXwQbgisD8fofoKSRVw\n b30m5q5BpUY+crDQ+CWZ77pHYI6WvVGI=","X-Gm-Gg":"AeBDietP96dTQePUYeXouWapBSUXP7aeaNs98V0jOZqNomaUvhUeq6O7fzzpSRck3te\n MC/Dn+GY06oGo90A0BNFlDqZkH2hM4LmdnUNbOHAAMKKwk1Fe9lMLjgxa5/t+tERgWRaSrpa9B+\n LreeVWbyqAlKV7xtuIEb1T/9zrbJV308oR/IZscdKTI7GiqL7gIPYJTQWidtc7oOgpJRg3JtwZE\n 3cAcTNkahsgBMouJ1Uw2ynvcWgU9M7VOY3v221mHTIq3IMbvUBXtXlwUw0hJKPLwgd99mTSLxJv\n eHziRxyq","X-Received":"by 2002:a17:903:124e:b0:2b2:ec6d:16c9 with SMTP id\n d9443c01a7336-2b2ec6d19bemr49713725ad.44.1776070432052; Mon, 13 Apr 2026\n 01:53:52 -0700 (PDT)","MIME-Version":"1.0","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOrVGwKbHdofQ9TqBAXYObL5Yu+J4ZnTeb5bD+pNve3zPw@mail.gmail.com>\n <0305rr41-n79q-q3po-222p-0p6468979827@fhfr.qr>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>","In-Reply-To":"<po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>","From":"\"H.J. Lu\" <hjl.tools@gmail.com>","Date":"Mon, 13 Apr 2026 16:53:15 +0800","X-Gm-Features":"AQROBzACGlKda4-TiX-v1H1FHInMqa2RLHZa0BAowa1hz-hzOcN--4HIYj3UBE8","Message-ID":"\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","To":"Richard Biener <rguenther@suse.de>","Cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676590,"web_url":"http://patchwork.ozlabs.org/comment/3676590/","msgid":"<2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","list_archive_url":null,"date":"2026-04-13T09:23:59","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Mon, 13 Apr 2026, H.J. Lu wrote:\n\n> On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> >\n> > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> >\n> > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > >\n> > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > >\n> > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > >\n> > > ...\n> > > > > >\n> > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > >\n> > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > >\n> > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > isn't available,\n> > > > > >\n> > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > local variable reference.\n> > > > > >\n> > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > base may point to stack or frame pointers.\n> > > > > >\n> > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > unchanged.\n> > > > > >\n> > > > > > PR target/109780\n> > > > > > PR target/109093\n> > > > > > PR target/123210\n> > > > > > PR target/124098\n> > > > > > PR target/124165\n> > > > > > PR target/124684\n> > > > > > PR target/124759\n> > > > > > PR target/124789\n> > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > (find_base_term): Remove static.\n> > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > (find_base_term): New prototype.\n> > > > >\n> > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > implementation is in alias.cc\n> > > >\n> > > > Done.\n> > > >\n> > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > >  {\n> > > > > ...\n> > > > >   /* Check RTL points-to info.  */\n> > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > >   if (!base)\n> > > > > ...\n> > > > >\n> > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > positive early out.  Thus\n> > > > >\n> > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > >   if (base\n> > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > >     return;\n> > > >\n> > > > I changed it to\n> > > >\n> > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > >   if (base)\n> > > >     {\n> > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > >         alignment = mem_align;\n> > > >       return;\n> > > >     }\n> >\n> > That looks good.\n> >\n> > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > rewriting\n> > > > >\n> > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > >\n> > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > *)&k] ] [116]))\n> > > > >\n> > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > >               rtx x = DECL_RTL (var);\n> > > > >               if (MEM_P (x))\n> > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > >\n> > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > case might be done entirely on decl devel by using\n> > > > >\n> > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > >       return;\n> > > > >\n> > > > > no need to dispatch through DECL_RTL?\n> > > >\n> > > > I changed it to\n> > > >\n> > > >      else if (decl_in_symtab_p (var))\n> > > >         return;\n> > > >\n> > > > > and the end of the function should have the conservative fallback:\n> > > > >\n> > > > >   alignment = mem_align;\n> > > > > }\n> > > > >\n> > > > > Thanks,\n> > > > > Richard.\n> > > > >\n> > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > >\n> > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > >\n> > > > > >\n> > > > >\n> > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > isn't available,\n> > > >\n> > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > static/external variable reference.\n> > > >\n> > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > base may point to stack or frame pointers.\n> > > >\n> > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > unchanged.\n> > > >\n> > > > PR target/109780\n> > > > PR target/109093\n> > > > PR target/123210\n> > > > PR target/124098\n> > > > PR target/124165\n> > > > PR target/124684\n> > > > PR target/124759\n> > > > PR target/124789\n> > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > (find_base_term): Remove static.\n> > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > init_alias_analysis and end_alias_analysis.\n> > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > * alias.h (find_base_term): New prototype.\n> > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > (ix86_find_all_reg_uses): Likewise.\n> > > > (ix86_access_stack_p): Likewise.\n> > > > (ix86_need_alignment_p_2): Likewise.\n> > > > (ix86_need_alignment_p_1): Likewise.\n> > > > (ix86_need_alignment_p): Likewise.\n> > > > (ix86_update_stack_alignment_2): New function.\n> > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > (ix86_update_stack_alignment): Rewrite.\n> > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > true, call ix86_update_stack_alignment on each INSN.\n> > > >\n> > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > >\n> > > > --\n> > > > H.J.\n> > >\n> > > Some updates:\n> > >\n> > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > 2.  Use\n> > >\n> > >       if (TREE_CODE (var) == PARM_DECL\n> > >           || TREE_CODE (var) == MEM_REF\n> > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > >           || decl_in_symtab_p (var))\n> > >         return;\n> >\n> > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > neither is skipping for PARM_DECL since that will also hit on\n> > callee copies with larger alignment.\n> >\n> >    if (VAR_P (var) && decl_in_symtab_p (var))\n> >      return;\n> >\n> > or\n> >\n> >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> >      return;\n> >\n> > would be both OK (I think the latter is more to the point).\n> >\n> > The PARM_DECL case should be catched by find_base_term which\n> > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > (but not for the callee copy which should be based on\n> > FRAME_POINTER_REGNUM).\n> >\n> > The address-space case chould be handled generally at the toplevel,\n> >\n> >   /* All stack is in the generic address space.  */\n> >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> >     return;\n> >\n> >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> >               (reg:V4DI 20 xmm0 [117]))\n> >\n> >          from gcc.target/i386/pr124098.c,\n> >\n> > I don't see how to easily handle this case.  GIMPLE points-to\n> > info (which would be accessible through _34) does currently not\n> > track a separate \"may point to (local) stack\" - that would be\n> > straight-forward to add though (but it increasingly feels like\n> > something to do for stage1).\n> \n> What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> xfail it?\n\nGiven all relevant bugs are in FIXED state right now I would suggest\nto try not disrupt stage4 further but postone this cleanup to stage1\nwith the eventual goal to backport for 16.2?\n\nYou can check whether the attached patch to add\nptr_deref_may_alias_auto_p works, you'd use it like ...\n\n> >\n> >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > {ref-all})s_1(D) & 4294967280B] ] [103])\n> >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> >\n> >          from gcc.target/i386/pr53907.c and\n> >\n> > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > which means it's likely an incoming parameter.  I would have expected\n> > that RTL PTA analysis would assign it some class, but it's\n> > pretty weak PTA.  Matching it explicitly with\n> >\n> > if (TREE_CODE (var) == MEM_REF\n> >     || TREE_CODE (var) == TARGET_MEM_REF)\n> >   {\n> >     tree ptr = TREE_OPERAND (var, 0);\n> >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> >       ptr = TREE_OPERAND (ptr, 0);\n\n        if (!ptr_deref_may_alias_auto_p (ptr))\n          return;\n\nDoes that resolve the testcases?\n\nRichard.\n\n> >     /* An access based on an incoming pointer cannot point to\n> >        local stack.  */\n> >     if (TREE_CODE (ptr) == SSA_NAME\n> >         && SSA_NAME_IS_DEFAULT_DEF (ptr)\n> >         && TREE_CODE (SSA_NAME_VAR (ptr)) == PARM_DECL)\n> >       return;\n> >   }\n> >\n> > would be possible, but similar to the above case GIMPLE level PTA\n> > could track this as does-not-point-to-local-stack.\n> >\n> > Richard.\n> \n> \n> \n>","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=YlALcpKz;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ZXpJqXkH;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=YlALcpKz;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ZXpJqXkH;\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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=YlALcpKz;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ZXpJqXkH;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=YlALcpKz;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ZXpJqXkH","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"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 4fvMS25JcDz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 19:24:34 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 891484BA2E29\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 09:24:32 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id DF4564BA2E09\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 09:24:00 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id ADB276A895;\n Mon, 13 Apr 2026 09:23:59 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 891484BA2E29","OpenDKIM Filter v2.11.0 sourceware.org DF4564BA2E09"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org DF4564BA2E09","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org DF4564BA2E09","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776072241; cv=none;\n b=XS+SayXsBtZEtNN8xQczmJU/CBASch2UfV2hWDyN4soCvbhiJ8f4QP9ziGo+IFXvIKlP5kbSk+JzRblR59ZYR9u8NQyDx56cerFu3hAksRITA2mxfkFHvdaXHTXKM8XGwzkzbNv+n3srrq+YPxQsJXNxxuR79HQA8A/1UGrMcPw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776072241; c=relaxed/simple;\n bh=ucC9/4QpFgtDBcLVj9b9MpPKesRr4j/6Et/eJmMgyRQ=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=dOf6oTIbwrLJFrQjuji65SuJsGLQbMIPsgUZPk1FHLCsSAwGd0w5cMZ786cLkwV8frRhcNpnuTHJxuQTjP8i4ApS5WU43vsmNtzPzxHOqvV5B0j/sJH7CuVLc9usyipiquy98yGwDqK5MgCRa4HtMWpTjEPfHlJp2l0yoCEQaH4=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776072239;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NiL9xrrfdUA/bJJ70i/YoU1AFKAYwOEyAp0aF1uew4s=;\n b=YlALcpKzDpvq4ARhO47ycDkHDqCCxO199lNMMZZnJNwLo5q38jziHchB3bsOudWFflaLZ2\n hzhduYf7+u0ptRQSKEk+k0/igIYCi9T1optES91xm1A+ol5aE2gt2jaBwkq+J/RZFpn8pS\n vbc0iifPoAUm0RU/27HhK0ODpwbEzfQ=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776072239;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NiL9xrrfdUA/bJJ70i/YoU1AFKAYwOEyAp0aF1uew4s=;\n b=ZXpJqXkHr2OQrn1drlAE75usG+qSsUZQN+CJfnw484tQ9XUlSAv01Q51LrXHTsYdbFzWzs\n KdxLyXN+QYnqUjAw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776072239;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NiL9xrrfdUA/bJJ70i/YoU1AFKAYwOEyAp0aF1uew4s=;\n b=YlALcpKzDpvq4ARhO47ycDkHDqCCxO199lNMMZZnJNwLo5q38jziHchB3bsOudWFflaLZ2\n hzhduYf7+u0ptRQSKEk+k0/igIYCi9T1optES91xm1A+ol5aE2gt2jaBwkq+J/RZFpn8pS\n vbc0iifPoAUm0RU/27HhK0ODpwbEzfQ=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776072239;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NiL9xrrfdUA/bJJ70i/YoU1AFKAYwOEyAp0aF1uew4s=;\n b=ZXpJqXkHr2OQrn1drlAE75usG+qSsUZQN+CJfnw484tQ9XUlSAv01Q51LrXHTsYdbFzWzs\n KdxLyXN+QYnqUjAw=="],"Date":"Mon, 13 Apr 2026 11:23:59 +0200 (CEST)","From":"Richard Biener <rguenther@suse.de>","To":"\"H.J. Lu\" <hjl.tools@gmail.com>","cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","In-Reply-To":"\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>","Message-ID":"<2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/mixed;\n boundary=\"-1475677436-1880779666-1776072239=:28865\"","X-Spamd-Result":"default: False [-1.70 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000];\n MIME_BASE64_TEXT_BOGUS(1.00)[];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[];\n MIME_GOOD(-0.10)[multipart/mixed,text/plain];\n TAGGED_RCPT(0.00)[]; RCVD_COUNT_ZERO(0.00)[0];\n FUZZY_RATELIMITED(0.00)[rspamd.com]; MISSING_XM_UA(0.00)[];\n ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+];\n FREEMAIL_TO(0.00)[gmail.com];\n FREEMAIL_ENVRCPT(0.00)[gmail.com];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n FROM_HAS_DN(0.00)[];\n FREEMAIL_CC(0.00)[gcc.gnu.org,gmail.com,intel.com,gentoo.org,googlemail.com];\n RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[];\n TO_MATCH_ENVRCPT_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[gnu.org:email,suse.de:email];\n TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676604,"web_url":"http://patchwork.ozlabs.org/comment/3676604/","msgid":"<7nbov2w7q46jtkwyytge2h3dnvxbj4zzarw7h5mhxbbzspuub3@7jphznycm2ka>","list_archive_url":null,"date":"2026-04-13T09:41:56","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":87068,"url":"http://patchwork.ozlabs.org/api/people/87068/","name":"Filip Kastl","email":"fkastl@suse.cz"},"content":"On Mon 2026-04-13 11:23:59, Richard Biener wrote:\n> The following records whether a points-to solution contains any\n> local automatic variables, not including parameters or result storage.\n\nWait so does ptr_deref_may_alias_auto_p say true for parameters and result\nstorage?  Because from the commit message it seems to me it does *not*, but\n(see bellow) ...\n\n> \n> \t* tree-ssa-alias.h (pt_solution::vars_contains_auto): New.\n> \t(ptr_deref_may_alias_auto_p): Declare.\n> \t(pt_solution_includes_auto): Likewise.\n> \t* tree-ssa-structalias.cc (set_uids_in_ptset): Record auto\n> \tvariables.\n> \t(pt_solution_includes_auto): New function.\n> \t(ipa_escaped_pt): Adjust.\n> \t* tree-ssa-alias.cc (ptr_deref_may_alias_auto_p): New function.\n> ---\n>  gcc/tree-ssa-alias.cc       | 24 ++++++++++++++++++++++++\n>  gcc/tree-ssa-alias.h        |  4 ++++\n>  gcc/tree-ssa-structalias.cc | 30 +++++++++++++++++++++++++++++-\n>  3 files changed, 57 insertions(+), 1 deletion(-)\n> \n> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc\n> index f662924b07f..e884d7e7012 100644\n> --- a/gcc/tree-ssa-alias.cc\n> +++ b/gcc/tree-ssa-alias.cc\n> @@ -238,6 +238,30 @@ ptr_deref_may_alias_global_p (tree ptr, bool escaped_local_p)\n>    return pt_solution_includes_global (&pi->pt, escaped_local_p);\n>  }\n>  \n> +/* Return true, if dereferencing PTR may alias with a local automatic\n> +   variable.  */\n> +\n> +bool\n> +ptr_deref_may_alias_auto_p (tree ptr)\n> +{\n> +  struct ptr_info_def *pi;\n> +\n> +  /* If we end up with a pointer constant here that may point\n> +     to local stack memory.  */\n> +  if (TREE_CODE (ptr) != SSA_NAME)\n> +    return true;\n> +\n> +  pi = SSA_NAME_PTR_INFO (ptr);\n> +\n> +  /* If we do not have points-to information for this variable,\n> +     we have to punt.  */\n> +  if (!pi)\n> +    return true;\n> +\n> +  return pt_solution_includes_auto (&pi->pt);\n> +}\n> +\n> +\n>  /* Return true if dereferencing PTR may alias DECL.\n>     The caller is responsible for applying TBAA to see if PTR\n>     may access DECL at all.  */\n> diff --git a/gcc/tree-ssa-alias.h b/gcc/tree-ssa-alias.h\n> index e0785c5d4bb..ccac9c539bb 100644\n> --- a/gcc/tree-ssa-alias.h\n> +++ b/gcc/tree-ssa-alias.h\n> @@ -54,6 +54,8 @@ struct GTY(()) pt_solution\n>  \n>    /* Nonzero if the vars bitmap includes a variable included in 'nonlocal'.  */\n>    unsigned int vars_contains_nonlocal : 1;\n> +  /* Nonzero if the vars bitmap includes a local automatic variable.  */\n> +  unsigned int vars_contains_auto : 1;\n>    /* Nonzero if the vars bitmap includes a variable included in 'escaped'.  */\n>    unsigned int vars_contains_escaped : 1;\n>    /* Nonzero if the vars bitmap includes a anonymous heap variable that\n> @@ -127,6 +129,7 @@ extern tree ao_ref_base_alias_ptr_type (ao_ref *);\n>  extern bool ao_ref_alignment (ao_ref *, unsigned int *,\n>  \t\t\t      unsigned HOST_WIDE_INT *);\n>  extern bool ptr_deref_may_alias_global_p (tree, bool);\n> +extern bool ptr_deref_may_alias_auto_p (tree);\n>  extern bool ptr_derefs_may_alias_p (tree, tree);\n>  extern bool ptrs_compare_unequal (tree, tree);\n>  extern bool ref_may_alias_global_p (tree, bool);\n> @@ -182,6 +185,7 @@ extern unsigned int compute_may_aliases (void);\n>  extern bool pt_solution_empty_p (const pt_solution *);\n>  extern bool pt_solution_singleton_or_null_p (struct pt_solution *, unsigned *);\n>  extern bool pt_solution_includes_global (struct pt_solution *, bool);\n> +extern bool pt_solution_includes_auto (struct pt_solution *);\n>  extern bool pt_solution_includes (struct pt_solution *, const_tree);\n>  extern bool pt_solution_includes_const_pool (struct pt_solution *);\n>  extern bool pt_solutions_intersect (struct pt_solution *, struct pt_solution *);\n> diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc\n> index e4a185d0f84..806a10d980b 100644\n> --- a/gcc/tree-ssa-structalias.cc\n> +++ b/gcc/tree-ssa-structalias.cc\n> @@ -801,6 +801,13 @@ set_uids_in_ptset (bitmap into, bitmap from, struct pt_solution *pt,\n>  \t\t  && ! auto_var_in_fn_p (vi->decl, fndecl)))\n>  \t    pt->vars_contains_nonlocal = true;\n>  \n> +\t  /* If the variable is an automatic in the local stack frame, record\n> +\t     that.  Note this includes PARM_DECL and RESULT_DECL which\n> +\t     are managed by the caller.  */\n\n... from this comment it seems to me it *does*.  Just checking if I perhaps\nfound a mistake or if I just don't understand the patch.\n\nCheers,\nFilip\n\n> +\t  if (VAR_P (vi->decl)\n> +\t      && auto_var_in_fn_p (vi->decl, fndecl))\n> +\t    pt->vars_contains_auto = true;\n> +\n>  \t  /* If we have a variable that is interposable record that fact\n>  \t     for pointer comparison simplification.  */\n>  \t  if (VAR_P (vi->decl)\n> @@ -1120,6 +1127,27 @@ pt_solution_includes_global (struct pt_solution *pt, bool escaped_local_p)\n>    return false;\n>  }\n>  \n> +/* Return true if the points-to solution *PT includes local automatic\n> +   storage.  */\n> +\n> +bool\n> +pt_solution_includes_auto (struct pt_solution *pt)\n> +{\n> +  if (pt->anything\n> +      || pt->vars_contains_auto)\n> +    return true;\n> +\n> +  /* 'escaped' is also a placeholder so we have to look into it.  */\n> +  if (pt->escaped)\n> +    return pt_solution_includes_auto (&cfun->gimple_df->escaped);\n> +\n> +  if (pt->ipa_escaped)\n> +    return pt_solution_includes_auto (&ipa_escaped_pt);\n> +\n> +  return false;\n> +}\n> +\n> +\n>  /* Return true if the points-to solution *PT includes the variable\n>     declaration DECL.  */\n>  \n> @@ -1803,7 +1831,7 @@ make_pass_build_ealias (gcc::context *ctxt)\n>  /* IPA PTA solutions for ESCAPED.  */\n>  struct pt_solution ipa_escaped_pt\n>    = { true, false, false, false, false, false,\n> -      false, false, false, false, false, NULL };\n> +      false, false, false, false, false, false, NULL };\n>  \n>  \n>  /* Execute the driver for IPA PTA.  */\n> -- \n> 2.51.0\n>","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=T+TJnskq;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ICcS3YyB;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=T+TJnskq;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ICcS3YyB;\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=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=T+TJnskq;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ICcS3YyB;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=T+TJnskq;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=ICcS3YyB","sourceware.org;\n dmarc=none (p=none dis=none) header.from=suse.cz","sourceware.org; spf=pass smtp.mailfrom=suse.cz","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"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 4fvMrj4Nxtz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 19:42:28 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 1435F4BA2E2B\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 09:42:26 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id 57F7E4BA2E09\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 09:41:57 +0000 (GMT)","from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id 5415A6A88F;\n Mon, 13 Apr 2026 09:41:56 +0000 (UTC)","from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4BA624AE03;\n Mon, 13 Apr 2026 09:41:56 +0000 (UTC)","from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])\n by imap1.dmz-prg2.suse.org with ESMTPSA id w7tzEmS63GntXAAAD6G6ig\n (envelope-from <fkastl@suse.cz>); Mon, 13 Apr 2026 09:41:56 +0000"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 1435F4BA2E2B","OpenDKIM Filter v2.11.0 sourceware.org 57F7E4BA2E09"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 57F7E4BA2E09","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 57F7E4BA2E09","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776073317; cv=none;\n b=jAAUXC5TLdne2bewk38hix3i21uu0duSnjT6LhP10Wj9KFQhNsQ/wjq25YXao3XnYa8ON0vKhgWjiD40VpHm3BHGgXtLiFqx316RqyHW9g4AQrh48rgwevYwBVFBiPr3cgjcqUFFLeuujGRN0UP6r9tVr0l+yqmbQtgjgOoXix4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776073317; c=relaxed/simple;\n bh=xZ92XjHI+iHtNZN2zDDMliw6rTS/O/y/YX2M14rFfyY=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=MhsREVRtAfLDlNBJ7liXZOsf3MwdQL2kRUyjkgYypFmyLNmFacXc2ylCU9QWCYvhNxpoNZ4OQmNt+Qkie0nfmut/4MOT4uaNiZZORudIlVBQ22m2Z1Nibe6oOQoyOuJ2ZB8D/lRpTAORqvyu7NA/7npq/1KvTpBdmsCnPZOCyBQ=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1776073316;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=6u8/lL7z9BSqNwVgjA6lfSUQnpitFtTCbek/W6CU3lM=;\n b=T+TJnskqrRQfQ2DgK6TXviouYWFG1Ve/UwCIRxB/6v47QmQvJVYG12ppZzcmQp+bFtwDyy\n d0DBAMyhq6nMXyEPdg0POYfXTqiVu9rXVuWt6UIEdYNZ1fPwX6tM65XVVSxvPiVfAoy5Bd\n ++WmAi5j4HZ7rdN5kuxq/c0WrGNpF94=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1776073316;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=6u8/lL7z9BSqNwVgjA6lfSUQnpitFtTCbek/W6CU3lM=;\n b=ICcS3YyB1rbXQrYRbHdx+3DRS3zCWXd4omVjhiLjYOkpkOSnZk90vdZbMgiTQo/9eku38O\n io0pGiGyRKOLZdCA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1776073316;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=6u8/lL7z9BSqNwVgjA6lfSUQnpitFtTCbek/W6CU3lM=;\n b=T+TJnskqrRQfQ2DgK6TXviouYWFG1Ve/UwCIRxB/6v47QmQvJVYG12ppZzcmQp+bFtwDyy\n d0DBAMyhq6nMXyEPdg0POYfXTqiVu9rXVuWt6UIEdYNZ1fPwX6tM65XVVSxvPiVfAoy5Bd\n ++WmAi5j4HZ7rdN5kuxq/c0WrGNpF94=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1776073316;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=6u8/lL7z9BSqNwVgjA6lfSUQnpitFtTCbek/W6CU3lM=;\n b=ICcS3YyB1rbXQrYRbHdx+3DRS3zCWXd4omVjhiLjYOkpkOSnZk90vdZbMgiTQo/9eku38O\n io0pGiGyRKOLZdCA=="],"Date":"Mon, 13 Apr 2026 11:41:56 +0200","From":"Filip Kastl <fkastl@suse.cz>","To":"Richard Biener <rguenther@suse.de>","Cc":"\"H.J. Lu\" <hjl.tools@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>,\n Uros Bizjak <ubizjak@gmail.com>, Hongtao Liu <hongtao.liu@intel.com>,\n Sam James <sam@gentoo.org>, Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","Message-ID":"<7nbov2w7q46jtkwyytge2h3dnvxbj4zzarw7h5mhxbbzspuub3@7jphznycm2ka>","References":"<4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","X-Spamd-Result":"default: False [-6.30 / 50.00]; REPLY(-4.00)[];\n BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[];\n NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n TAGGED_RCPT(0.00)[]; RCVD_TLS_ALL(0.00)[];\n RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[];\n FUZZY_RATELIMITED(0.00)[rspamd.com]; MISSING_XM_UA(0.00)[];\n RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_ENVRCPT(0.00)[gmail.com];\n DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];\n FROM_HAS_DN(0.00)[];\n FREEMAIL_CC(0.00)[gmail.com,gcc.gnu.org,intel.com,gentoo.org,googlemail.com];\n MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[];\n RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n TO_DN_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[tree-ssa-structalias.cc:url,\n imap1.dmz-prg2.suse.org:helo, tree-ssa-alias.cc:url]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676633,"web_url":"http://patchwork.ozlabs.org/comment/3676633/","msgid":"<CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>","list_archive_url":null,"date":"2026-04-13T10:22:16","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Mon, Apr 13, 2026 at 5:24 PM Richard Biener <rguenther@suse.de> wrote:\n>\n> On Mon, 13 Apr 2026, H.J. Lu wrote:\n>\n> > On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> > >\n> > > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> > >\n> > > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > > >\n> > > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > >\n> > > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > > >\n> > > > ...\n> > > > > > >\n> > > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > > >\n> > > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > > >\n> > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > isn't available,\n> > > > > > >\n> > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > local variable reference.\n> > > > > > >\n> > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > base may point to stack or frame pointers.\n> > > > > > >\n> > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > unchanged.\n> > > > > > >\n> > > > > > > PR target/109780\n> > > > > > > PR target/109093\n> > > > > > > PR target/123210\n> > > > > > > PR target/124098\n> > > > > > > PR target/124165\n> > > > > > > PR target/124684\n> > > > > > > PR target/124759\n> > > > > > > PR target/124789\n> > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > (find_base_term): Remove static.\n> > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > (find_base_term): New prototype.\n> > > > > >\n> > > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > > implementation is in alias.cc\n> > > > >\n> > > > > Done.\n> > > > >\n> > > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > > >  {\n> > > > > > ...\n> > > > > >   /* Check RTL points-to info.  */\n> > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > >   if (!base)\n> > > > > > ...\n> > > > > >\n> > > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > > positive early out.  Thus\n> > > > > >\n> > > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > >   if (base\n> > > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > >     return;\n> > > > >\n> > > > > I changed it to\n> > > > >\n> > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > >   if (base)\n> > > > >     {\n> > > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > >         alignment = mem_align;\n> > > > >       return;\n> > > > >     }\n> > >\n> > > That looks good.\n> > >\n> > > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > > rewriting\n> > > > > >\n> > > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > > >\n> > > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > > *)&k] ] [116]))\n> > > > > >\n> > > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > > >               rtx x = DECL_RTL (var);\n> > > > > >               if (MEM_P (x))\n> > > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > > >\n> > > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > > case might be done entirely on decl devel by using\n> > > > > >\n> > > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > > >       return;\n> > > > > >\n> > > > > > no need to dispatch through DECL_RTL?\n> > > > >\n> > > > > I changed it to\n> > > > >\n> > > > >      else if (decl_in_symtab_p (var))\n> > > > >         return;\n> > > > >\n> > > > > > and the end of the function should have the conservative fallback:\n> > > > > >\n> > > > > >   alignment = mem_align;\n> > > > > > }\n> > > > > >\n> > > > > > Thanks,\n> > > > > > Richard.\n> > > > > >\n> > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > >\n> > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > >\n> > > > > > >\n> > > > > >\n> > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > isn't available,\n> > > > >\n> > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > static/external variable reference.\n> > > > >\n> > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > base may point to stack or frame pointers.\n> > > > >\n> > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > unchanged.\n> > > > >\n> > > > > PR target/109780\n> > > > > PR target/109093\n> > > > > PR target/123210\n> > > > > PR target/124098\n> > > > > PR target/124165\n> > > > > PR target/124684\n> > > > > PR target/124759\n> > > > > PR target/124789\n> > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > (find_base_term): Remove static.\n> > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > init_alias_analysis and end_alias_analysis.\n> > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > * alias.h (find_base_term): New prototype.\n> > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > (ix86_access_stack_p): Likewise.\n> > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > (ix86_need_alignment_p): Likewise.\n> > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > >\n> > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > >\n> > > > > --\n> > > > > H.J.\n> > > >\n> > > > Some updates:\n> > > >\n> > > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > > 2.  Use\n> > > >\n> > > >       if (TREE_CODE (var) == PARM_DECL\n> > > >           || TREE_CODE (var) == MEM_REF\n> > > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > > >           || decl_in_symtab_p (var))\n> > > >         return;\n> > >\n> > > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > > neither is skipping for PARM_DECL since that will also hit on\n> > > callee copies with larger alignment.\n> > >\n> > >    if (VAR_P (var) && decl_in_symtab_p (var))\n> > >      return;\n> > >\n> > > or\n> > >\n> > >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> > >      return;\n> > >\n> > > would be both OK (I think the latter is more to the point).\n> > >\n> > > The PARM_DECL case should be catched by find_base_term which\n> > > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > > (but not for the callee copy which should be based on\n> > > FRAME_POINTER_REGNUM).\n> > >\n> > > The address-space case chould be handled generally at the toplevel,\n> > >\n> > >   /* All stack is in the generic address space.  */\n> > >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> > >     return;\n> > >\n> > >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> > >               (reg:V4DI 20 xmm0 [117]))\n> > >\n> > >          from gcc.target/i386/pr124098.c,\n> > >\n> > > I don't see how to easily handle this case.  GIMPLE points-to\n> > > info (which would be accessible through _34) does currently not\n> > > track a separate \"may point to (local) stack\" - that would be\n> > > straight-forward to add though (but it increasingly feels like\n> > > something to do for stage1).\n> >\n> > What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> > xfail it?\n>\n> Given all relevant bugs are in FIXED state right now I would suggest\n> to try not disrupt stage4 further but postone this cleanup to stage1\n> with the eventual goal to backport for 16.2?\n>\n> You can check whether the attached patch to add\n> ptr_deref_may_alias_auto_p works, you'd use it like ...\n>\n> > >\n> > >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > > {ref-all})s_1(D) & 4294967280B] ] [103])\n> > >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> > >\n> > >          from gcc.target/i386/pr53907.c and\n> > >\n> > > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > > which means it's likely an incoming parameter.  I would have expected\n> > > that RTL PTA analysis would assign it some class, but it's\n> > > pretty weak PTA.  Matching it explicitly with\n> > >\n> > > if (TREE_CODE (var) == MEM_REF\n> > >     || TREE_CODE (var) == TARGET_MEM_REF)\n> > >   {\n> > >     tree ptr = TREE_OPERAND (var, 0);\n> > >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> > >       ptr = TREE_OPERAND (ptr, 0);\n>\n>         if (!ptr_deref_may_alias_auto_p (ptr))\n>           return;\n>\n> Does that resolve the testcases?\n\nNo,\n\n8697     if (!ptr_deref_may_alias_auto_p (ptr))\n(gdb) call debug (ptr)\n <ssa_name 0x7fffe964e210\n    type <pointer_type 0x7fffe9825000\n        type <void_type 0x7fffe981df18 void VOID\n            align:8 warn_if_not_align:0 symtab:0 alias-set -1\ncanonical-type 0x7fffe981df18\n            pointer_to_this <pointer_type 0x7fffe9825000>>\n        public unsigned DI\n        size <integer_cst 0x7fffe9802f60 constant 64>\n        unit-size <integer_cst 0x7fffe9802f78 constant 8>\n        align:64 warn_if_not_align:0 symtab:0 alias-set -1\ncanonical-type 0x7fffe9825000\n        pointer_to_this <pointer_type 0x7fffe982da80>>\n    visited\n    def_stmt _34 = (void *) ivtmp.23_37;\n    version:34\n    ptr-info 0x7fffe9650a80>\n(gdb) step\nptr_deref_may_alias_auto_p (ptr=0x7fffe964e210)\n    at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-alias.cc:251\n251   if (TREE_CODE (ptr) != SSA_NAME)\n(gdb) next\n254   pi = SSA_NAME_PTR_INFO (ptr);\n(gdb)\n258   if (!pi)\n(gdb)\n261   return pt_solution_includes_auto (&pi->pt);\n(gdb) step\npt_solution_includes_auto (pt=0x7fffe9650a80)\n    at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-structalias.cc:1136\n1136   if (pt->anything\n(gdb) p pt->anything\n$1 = 1\n(gdb) next\n1138     return true;\n(gdb)\n\n> Richard.\n>\n> > >     /* An access based on an incoming pointer cannot point to\n> > >        local stack.  */\n> > >     if (TREE_CODE (ptr) == SSA_NAME\n> > >         && SSA_NAME_IS_DEFAULT_DEF (ptr)\n> > >         && TREE_CODE (SSA_NAME_VAR (ptr)) == PARM_DECL)\n> > >       return;\n> > >   }\n> > >\n> > > would be possible, but similar to the above case GIMPLE level PTA\n> > > could track this as does-not-point-to-local-stack.\n> > >\n> > > Richard.\n> >\n> >\n> >\n> >\n>\n> --\n> Richard Biener <rguenther@suse.de>\n> SUSE Software Solutions Germany GmbH,\n> Frankenstrasse 146, 90461 Nuernberg, Germany;\n> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=b0fbxGEP;\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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=b0fbxGEP","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.210.179"],"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 4fvNm547NPz1yDF\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 20:23:32 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6B98F4BA2E10\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 10:23:30 +0000 (GMT)","from mail-pf1-f179.google.com (mail-pf1-f179.google.com\n [209.85.210.179])\n by sourceware.org (Postfix) with ESMTPS id 955774BA2E10\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 10:22:54 +0000 (GMT)","by mail-pf1-f179.google.com with SMTP id\n d2e1a72fcca58-82f351ca23cso419663b3a.2\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 03:22:54 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6B98F4BA2E10","OpenDKIM Filter v2.11.0 sourceware.org 955774BA2E10"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 955774BA2E10","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 955774BA2E10","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776075774; cv=pass;\n b=ju8N/NpPtX8usvi7GshVnsfi01C+KZUQ5M7Ii5woQkrmBTjq77SLqNcDjx7X3gfLyJtA3u9r3qkgOMVz0hsaoe6pUT5lLWVMwMPP3bu5oWr/XgMAn6p6P+fIuHSlMaF2KSnCgVYxhzkdB1CNBHzF/h9IoRmeaIqhq5hbN4EUna0=","i=1; a=rsa-sha256; t=1776075773; cv=none;\n d=google.com; s=arc-20240605;\n b=T38y2xGySY8xsTsvGucHcppg3fbI+jn8dLoJKMi5U/kudJeYmtpylIr2s4k5tb8l3c\n vIMy5BgGmvSLb1f2O/t6Sgf9knI33IWWlu0rOct/qRZhtbpznD59zm8vLT5SCTvoAab0\n hyi+737Jf2DnBNpdjMFpitPI65WUFQaAAGnPndo52X2aj+XulQ1EIVkVOYPmi10kJyVP\n yxXvhWYhPIakMaBwgEYmZdl7rEahhlM+eDioGncE3TwJUK1SzD9SEsZWTI110Rt5cVWl\n AEC3eBSTszLASo0kXaqBHVbc94fjo2RQ8OXWTDQV7VAPlU9z7gztQ7dsIhxlBWTeiIE8\n E1iA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776075774; c=relaxed/simple;\n bh=bQgdT1EDmF2408uURsEfdOvsUgFgK0vlN7KZHQzQkjE=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=oYcGBgAZL9eFvJomsjtGowg+iurONPlTmAAZZC5uqZw5ULTet9mH0B4WAFz9dHrBQ96flfFRY8vxY1YBYiFcpw1DxZ4SxGCz7BbMHRgnveGN42ECPj9PGNvhDvnTK5DDCi/bH9p4UCguxiyEf+q745ypBCQV3C29HDtzg4GmaSU=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=V20YC5qzb4TqfFMTXlAt12/MlG5KOiEmtG4t9x9gcwU=;\n fh=sFFq4wvy7UcSKlgT6RiqXOQFQjorSTnVHLzf7/o8kz4=;\n b=QJ0ofdVqaKjJNe+w2r7w8aSMEvdtmcc5tlrYeWMtu4+OXaUio2VyQ/9V39RfQmlqZw\n KMUvIsg+SW5q64vEhWLK/56A4DYUcVbZTNnGVThaiXK1hLPj1jyW5URfToOrlX2bj5+0\n b9Q5s50zhbCGw47T6IGD8h9f7at3IZwNiCdNjbz06Z5C/pALWvZYOyOaFf73yAJQaFqY\n 9WYZ4XjCZ5rjeL/5vk75YLYoO4Lk/i41gZwYi0qZWQwW8plpJxoEbVvervA5f5xjAB4h\n xEURupMXYv/49u3F84I8rv2r9AqtwP+Wceo+YYV8ZI0oB0C2+0uO/phSZ2yQifWIkwXZ\n 6t6A==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776075773; x=1776680573; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=V20YC5qzb4TqfFMTXlAt12/MlG5KOiEmtG4t9x9gcwU=;\n b=b0fbxGEP+r0otz9vyFQRyS2iQdwKxQsO5g4M6eKc/C5523C1cC5H+FIiW9nTB0lYo4\n 7twc4Ga7ryvu7+h0O+GcUAQf2S3t1enZk7gR5OEEoQjyzsDXh3FR4bgIbJTtakl3Smd9\n 9SndBd9JJA6l2PkngR7YLc0JKCnB6POf4uRseWz2QA1bKp0uEVXvOjyw2SAzL5/GUBTU\n 7jLMIe3qsMrP5WUKoSaVDnILJp1n+rshq1e69CM/ZTYWa9p8IKSMjFwfAxNYsI68VaGw\n SzKY1i6B3Ee3T7pwZKC9xBRGZuvENaqCO82el9QFvV1NA7vL8sZwxcduqIZ5l5rkZzJh\n CGJw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776075773; x=1776680573;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=V20YC5qzb4TqfFMTXlAt12/MlG5KOiEmtG4t9x9gcwU=;\n b=noeeNRWsucephlG0dyU4LpRuO8bthjQ6rHvx46o9MgCRQBRV/DZMJ60l0N5zeWQi62\n adRzmJL8QeM+xHxTGUR3ZLT/qGa4BnA1Z/mYGZROcdzXiFp3dnRuWXQQPd6J2MaT/OfP\n 0HkkMb3NbkO650kDrlfNJ9mfKAcBWF5Vuo6vDtGjP95MBEi9RdS7ByW7yYaSgQF6iWIk\n 45GhVgnm2xRWIdXITV1hr4JJw52xRieQtC1dFLeQOPZX8DZugVqXPQ7Nyyg9CfDzRVSg\n INXL/3E8yEg+6e5qU55eUFLPPYZq6TdVm54bUMwRSa/EeiEUDcGaJrYdT08TAD7Dhvyk\n +hzQ==","X-Gm-Message-State":"AOJu0Ywhfm2PVfysGuqHFX5dXWA/jG/G34qx60A9HF/KINR/KEXYV+lV\n 7OFUs47yaKqFGDCR42874vLNSdEssaab6M/cYOw4JT0zmW7dg3+CpdFZhMZaN8dj/XiCau2Qi6T\n 8qJ9eF3oK8VvdRT4iroreZb2MbDr1fwI=","X-Gm-Gg":"AeBDievqjXDLdRodZ6k8nc+9D4fttTmYXSttpNguU37zcqyhXh2y4gVsOdTddBTASyz\n pFMPIh8aZv2/b5Yl/4xGhwEcc6/LfF18WIepgjN1sA+iGicjYO8bEliqaqGNZL433QN4C/bH26h\n PMRuAZgBBN1p24iJ9+waVZy5N5jKy4zn0t1puAdWWl9raRn48GrcAD+zdDqAu1qjCtlkf6pO+M9\n XguzhLfA6dkSynsAlCdvNTW6DHRo25ADZ8G5QDjzNBWdY+CpWH4tHsZWglTVgBDtObGWOuuiAD6\n 5NeNQQ==","X-Received":"by 2002:aa7:8a52:0:b0:82f:1b1b:e16d with SMTP id\n d2e1a72fcca58-82f1b1c0e88mr7337428b3a.30.1776075772997; Mon, 13 Apr 2026\n 03:22:52 -0700 (PDT)","MIME-Version":"1.0","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","In-Reply-To":"<2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>","From":"\"H.J. Lu\" <hjl.tools@gmail.com>","Date":"Mon, 13 Apr 2026 18:22:16 +0800","X-Gm-Features":"AQROBzAXpIdxYDyUqXlVTRuoPGJz81p-KmvMqs1J6NbpJxhweFH4i59fOuhHE1I","Message-ID":"\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","To":"Richard Biener <rguenther@suse.de>","Cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676653,"web_url":"http://patchwork.ozlabs.org/comment/3676653/","msgid":"<CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>","list_archive_url":null,"date":"2026-04-13T11:13:33","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Mon, Apr 13, 2026 at 6:22 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n>\n> On Mon, Apr 13, 2026 at 5:24 PM Richard Biener <rguenther@suse.de> wrote:\n> >\n> > On Mon, 13 Apr 2026, H.J. Lu wrote:\n> >\n> > > On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> > > >\n> > > > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> > > >\n> > > > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > > > >\n> > > > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > > >\n> > > > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > > > >\n> > > > > ...\n> > > > > > > >\n> > > > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > > > >\n> > > > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > > > >\n> > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > isn't available,\n> > > > > > > >\n> > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > local variable reference.\n> > > > > > > >\n> > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > base may point to stack or frame pointers.\n> > > > > > > >\n> > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > unchanged.\n> > > > > > > >\n> > > > > > > > PR target/109780\n> > > > > > > > PR target/109093\n> > > > > > > > PR target/123210\n> > > > > > > > PR target/124098\n> > > > > > > > PR target/124165\n> > > > > > > > PR target/124684\n> > > > > > > > PR target/124759\n> > > > > > > > PR target/124789\n> > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > (find_base_term): Remove static.\n> > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > (find_base_term): New prototype.\n> > > > > > >\n> > > > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > > > implementation is in alias.cc\n> > > > > >\n> > > > > > Done.\n> > > > > >\n> > > > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > > > >  {\n> > > > > > > ...\n> > > > > > >   /* Check RTL points-to info.  */\n> > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > >   if (!base)\n> > > > > > > ...\n> > > > > > >\n> > > > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > > > positive early out.  Thus\n> > > > > > >\n> > > > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > >   if (base\n> > > > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > >     return;\n> > > > > >\n> > > > > > I changed it to\n> > > > > >\n> > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > >   if (base)\n> > > > > >     {\n> > > > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > >         alignment = mem_align;\n> > > > > >       return;\n> > > > > >     }\n> > > >\n> > > > That looks good.\n> > > >\n> > > > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > > > rewriting\n> > > > > > >\n> > > > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > > > >\n> > > > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > > > *)&k] ] [116]))\n> > > > > > >\n> > > > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > > > >               rtx x = DECL_RTL (var);\n> > > > > > >               if (MEM_P (x))\n> > > > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > > > >\n> > > > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > > > case might be done entirely on decl devel by using\n> > > > > > >\n> > > > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > > > >       return;\n> > > > > > >\n> > > > > > > no need to dispatch through DECL_RTL?\n> > > > > >\n> > > > > > I changed it to\n> > > > > >\n> > > > > >      else if (decl_in_symtab_p (var))\n> > > > > >         return;\n> > > > > >\n> > > > > > > and the end of the function should have the conservative fallback:\n> > > > > > >\n> > > > > > >   alignment = mem_align;\n> > > > > > > }\n> > > > > > >\n> > > > > > > Thanks,\n> > > > > > > Richard.\n> > > > > > >\n> > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > >\n> > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > >\n> > > > > > > >\n> > > > > > >\n> > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > isn't available,\n> > > > > >\n> > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > static/external variable reference.\n> > > > > >\n> > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > base may point to stack or frame pointers.\n> > > > > >\n> > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > unchanged.\n> > > > > >\n> > > > > > PR target/109780\n> > > > > > PR target/109093\n> > > > > > PR target/123210\n> > > > > > PR target/124098\n> > > > > > PR target/124165\n> > > > > > PR target/124684\n> > > > > > PR target/124759\n> > > > > > PR target/124789\n> > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > (find_base_term): Remove static.\n> > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > * alias.h (find_base_term): New prototype.\n> > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > >\n> > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > >\n> > > > > > --\n> > > > > > H.J.\n> > > > >\n> > > > > Some updates:\n> > > > >\n> > > > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > > > 2.  Use\n> > > > >\n> > > > >       if (TREE_CODE (var) == PARM_DECL\n> > > > >           || TREE_CODE (var) == MEM_REF\n> > > > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > > > >           || decl_in_symtab_p (var))\n> > > > >         return;\n> > > >\n> > > > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > > > neither is skipping for PARM_DECL since that will also hit on\n> > > > callee copies with larger alignment.\n> > > >\n> > > >    if (VAR_P (var) && decl_in_symtab_p (var))\n> > > >      return;\n> > > >\n> > > > or\n> > > >\n> > > >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> > > >      return;\n> > > >\n> > > > would be both OK (I think the latter is more to the point).\n> > > >\n> > > > The PARM_DECL case should be catched by find_base_term which\n> > > > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > > > (but not for the callee copy which should be based on\n> > > > FRAME_POINTER_REGNUM).\n> > > >\n> > > > The address-space case chould be handled generally at the toplevel,\n> > > >\n> > > >   /* All stack is in the generic address space.  */\n> > > >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> > > >     return;\n> > > >\n> > > >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > > > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> > > >               (reg:V4DI 20 xmm0 [117]))\n> > > >\n> > > >          from gcc.target/i386/pr124098.c,\n> > > >\n> > > > I don't see how to easily handle this case.  GIMPLE points-to\n> > > > info (which would be accessible through _34) does currently not\n> > > > track a separate \"may point to (local) stack\" - that would be\n> > > > straight-forward to add though (but it increasingly feels like\n> > > > something to do for stage1).\n> > >\n> > > What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> > > xfail it?\n> >\n> > Given all relevant bugs are in FIXED state right now I would suggest\n> > to try not disrupt stage4 further but postone this cleanup to stage1\n> > with the eventual goal to backport for 16.2?\n> >\n> > You can check whether the attached patch to add\n> > ptr_deref_may_alias_auto_p works, you'd use it like ...\n> >\n> > > >\n> > > >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > > > {ref-all})s_1(D) & 4294967280B] ] [103])\n> > > >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > > > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> > > >\n> > > >          from gcc.target/i386/pr53907.c and\n> > > >\n> > > > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > > > which means it's likely an incoming parameter.  I would have expected\n> > > > that RTL PTA analysis would assign it some class, but it's\n> > > > pretty weak PTA.  Matching it explicitly with\n> > > >\n> > > > if (TREE_CODE (var) == MEM_REF\n> > > >     || TREE_CODE (var) == TARGET_MEM_REF)\n> > > >   {\n> > > >     tree ptr = TREE_OPERAND (var, 0);\n> > > >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> > > >       ptr = TREE_OPERAND (ptr, 0);\n> >\n> >         if (!ptr_deref_may_alias_auto_p (ptr))\n> >           return;\n> >\n> > Does that resolve the testcases?\n>\n> No,\n>\n> 8697     if (!ptr_deref_may_alias_auto_p (ptr))\n> (gdb) call debug (ptr)\n>  <ssa_name 0x7fffe964e210\n>     type <pointer_type 0x7fffe9825000\n>         type <void_type 0x7fffe981df18 void VOID\n>             align:8 warn_if_not_align:0 symtab:0 alias-set -1\n> canonical-type 0x7fffe981df18\n>             pointer_to_this <pointer_type 0x7fffe9825000>>\n>         public unsigned DI\n>         size <integer_cst 0x7fffe9802f60 constant 64>\n>         unit-size <integer_cst 0x7fffe9802f78 constant 8>\n>         align:64 warn_if_not_align:0 symtab:0 alias-set -1\n> canonical-type 0x7fffe9825000\n>         pointer_to_this <pointer_type 0x7fffe982da80>>\n>     visited\n>     def_stmt _34 = (void *) ivtmp.23_37;\n>     version:34\n>     ptr-info 0x7fffe9650a80>\n> (gdb) step\n> ptr_deref_may_alias_auto_p (ptr=0x7fffe964e210)\n>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-alias.cc:251\n> 251   if (TREE_CODE (ptr) != SSA_NAME)\n> (gdb) next\n> 254   pi = SSA_NAME_PTR_INFO (ptr);\n> (gdb)\n> 258   if (!pi)\n> (gdb)\n> 261   return pt_solution_includes_auto (&pi->pt);\n> (gdb) step\n> pt_solution_includes_auto (pt=0x7fffe9650a80)\n>     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-structalias.cc:1136\n> 1136   if (pt->anything\n> (gdb) p pt->anything\n> $1 = 1\n> (gdb) next\n> 1138     return true;\n> (gdb)\n>\n\nFor\n\n----\nchar c, d;\n_BitInt(2048) b;\n\nvoid\nfoo (__int128, _BitInt(1024) a)\n{\n  b = NUM;\n  c %= (char)(a ?: d);\n}\n---\n\n-mavx2 -O2 fails when NUM == 0 or NUM == -1.","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=hbXCPOaf;\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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=hbXCPOaf","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.214.171"],"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 4fvPvD477Rz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 21:14:45 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 3ABF14BA5439\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 11:14:43 +0000 (GMT)","from mail-pl1-f171.google.com (mail-pl1-f171.google.com\n [209.85.214.171])\n by sourceware.org (Postfix) with ESMTPS id A58574BA5439\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 11:14:11 +0000 (GMT)","by mail-pl1-f171.google.com with SMTP id\n d9443c01a7336-2b2ea1b3962so7401695ad.0\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 04:14:11 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 3ABF14BA5439","OpenDKIM Filter v2.11.0 sourceware.org A58574BA5439"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A58574BA5439","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A58574BA5439","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776078851; cv=pass;\n b=sp9p0TWGWtj0Sv9SCpNXHG549L3DDnDgir6Qf7JEEvGslG0hO0LCeAUXc2eINEJGnrwq8WVJpRiaRlFUjkf9F9XI7w37wwrmGTT6nYkVg2E2ouE95N8sTGjuTl7WE3FggtqzCb5N4MHn5VjIA1LA3SHJx6zWAdu2LakmeasY2C4=","i=1; a=rsa-sha256; t=1776078850; cv=none;\n d=google.com; s=arc-20240605;\n b=PVwMoh96J6FpCJ7Vx2PoEEDrJ+hcP5OVcHCz9OgrlH2gl77zgoeiGDl0wG+spQcwmo\n t8DhXDMI+FDH4u7oIflKQxOO1FYx/Ni6LEIvs3JemYf8VX6po1a4k0Zi+jnfNtqBjIdp\n 0H+kyUDE8F+8CoNAjLWv8Jfc9efNmWNSb/iLqmTPR0Hkqt6KlsTCo8emORZuoCNx0+L+\n YeFhe8Bhc6qOgnb6SszqRx9ojKKsv5bF2uByfZywAS9xiRqrzCA2OwjEztToc5CML6lP\n Aoh719ykmcJPNHUZarM+ZIbuAT4q6IP0F6HVYmsAe4uRjxo2sEhy2hYQLAAYfmK5Lqz2\n d6lw=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776078851; c=relaxed/simple;\n bh=J9pHIuG9ALl+ga8xhf/yOwLSv5oFKYa+GFIxgS326a8=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=szDDUmNb+WmO+mI0a742jy/E2kMbduzZOqbKPpOnwBwKOJTM4belud/dlpDjbezZdr7Ad8WyEBLUFeAVlTnBYD5hQ8Tg6VdXDjJqJ2UKBnt5+lZ6e+6wJdQmY3PqSG9hSev/JcBXiqOw0mnQ4fUjYaRW9rpETsWAJt1pQZSAhm8=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=N5bdOIa5J0BCSvrVRnprFBprIdSHdTQYA+WHiBC4+S0=;\n fh=sFFq4wvy7UcSKlgT6RiqXOQFQjorSTnVHLzf7/o8kz4=;\n b=Xp8Hj0PaHQBI0PKeLatW4pxMG56A9YUTZnLcQaexNB44mNfWVMl0W6F1rKzmU8uA9d\n +OkMzpsyrUY8tdJTN9JUvLGTPJhaoD27582FZhBs9ngrHNdBtKW0XuJVKsbk0w+jof5F\n OqLL7+YB+GRBMxjyiyzRdDXO1c8+o+As0OZlkkWXMZ5rbDlUxXogEX2IwXzK4tgpUP5k\n GFuIauattws/HGS7XonWGEdJUJnyOGdywnw9/5LCxr19k4/dk+CubjJ8eqOXNM3LuQcH\n HVv1iEtzxMcTWDYLeai4Iz1GOPhfeQ5n7VpJqkVgtfzHaTf4jLbfUru4LHAh0SoMvr25\n 41bg==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776078850; x=1776683650; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=N5bdOIa5J0BCSvrVRnprFBprIdSHdTQYA+WHiBC4+S0=;\n b=hbXCPOaf/+/3iZfflnO63zfrBHRtncK7CFGHt2oJ8tWPBN3h8WiZB2NehCLHyiwCh0\n DOjBYCGBoHnpXIEYBY3P3yii0P7vfZzbJKGjN9aEFuaSHkT2kzgsuhpiiLF4OFj4wa/B\n 79TltQ1uz9qvP3GKz53q72Q5LWv8AJnr48JN79QtwE/j/x0l/JIAFQ5d10+dSxnxDRVG\n 4YzWhf4Oql+KCZS5NolOxVXEZQqcj1QJ+tfh//L4aC7zAru+UtZoriaF3ZhQ/ZApGcb3\n jHe7K8HQI1fzMet+iIFi1CtAGaUuZLgAWeA75wKnsFtXYZylixR/nDnVr2WyTGnAwcfK\n Vx2g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776078850; x=1776683650;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=N5bdOIa5J0BCSvrVRnprFBprIdSHdTQYA+WHiBC4+S0=;\n b=O96pgGWGsf/jc6T6vDBa55N5R9yT7egiyzeu1HyBu9q6k0MGTQmE/+/ygmgxPtv+zz\n MsaJCLeVKH/nRrrTAGDjQJfSWF6dS+7IpWq019AAgz9+qZn6XOGFO0GNRHVJCN31IOjM\n E9R0GPKrZ2CDSsMI7+b3CJC6A8i+xNAWA/Mdzx7CNNqsOkeXN8w7dpJPDLD36CXpJbyD\n m2BWZSrT9yOO4zT480XyttvR148H5u5uE+ip11U4u0jdfMqXPXxCTz9w8a7YIADvUPlD\n KLMQHxUjIH5K7ydb3qiWbZgF/2r8O79odGdONQjo/MwQN66mbOyB/DncVZ8iedJ6gFNy\n PZzg==","X-Gm-Message-State":"AOJu0YwXrqpYTDjijNEm54VM7Laniesg+I2ubtsrvhQdqs//wwRzJR1b\n Vv4xL3sMdc57zHC4gWvjuZcNT8DYhg5POsHUHkfTaQgJqKnsWdCQzHISY6jAKNlhAzfLK8dJ1eP\n 93erIedgUf9/yRQ4MS7kP/sKMTj8Oo/o=","X-Gm-Gg":"AeBDiesdLyp1XFlR2wycOuJgmWkRumHke6ad+Ax58lZLCVJW1rmrWx8nRWo3mmrDibk\n f8QSEaNUZFoLnpxEHSwtKm++ZlFXka/mL6zMKXylsSBspXw7c1lK62ShTg/75qV7LK6bJ4Fz54u\n wl5IayRbHprz4SayFJ1D7L/b+xqGtNm3WBE9P1tLdiA0OZSofHU/QkMUBn5KG7XFK1LRVaHTs4O\n rvsJry0PYU6Lrjxp431gyvfQrdPrAA3u8rNsBqWlRRtm+Pq7Fm9bKq2nqlxCmBDIuIKD89gNad5\n nUGLFw==","X-Received":"by 2002:a17:903:4b46:b0:2b0:6f21:8289 with SMTP id\n d9443c01a7336-2b2d5a45fe2mr138301715ad.25.1776078850343; Mon, 13 Apr 2026\n 04:14:10 -0700 (PDT)","MIME-Version":"1.0","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOrtsUqu1AgU=M9rgV1jcUB8YO12Aaekev+o5zFfi5PQNQ@mail.gmail.com>\n <8900r718-2q5q-7613-nsp5-o0s313r8p007@fhfr.qr>\n <CAMe9rOpyurp8_kBu00epcBvtpN+wHzWRu3W6jr-7qu3+xwp=Ww@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>","In-Reply-To":"\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>","From":"\"H.J. Lu\" <hjl.tools@gmail.com>","Date":"Mon, 13 Apr 2026 19:13:33 +0800","X-Gm-Features":"AQROBzCa2I4Ux-FH2ZWgOyDOmaMj4nG2k1Sh8C0niCjbBzgim-wZes5aXntpJAo","Message-ID":"\n <CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","To":"Richard Biener <rguenther@suse.de>","Cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676673,"web_url":"http://patchwork.ozlabs.org/comment/3676673/","msgid":"<o63so56q-p336-00r2-6562-9op0397rn881@fhfr.qr>","list_archive_url":null,"date":"2026-04-13T11:36:59","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Mon, 13 Apr 2026, Filip Kastl wrote:\n\n> On Mon 2026-04-13 11:23:59, Richard Biener wrote:\n> > The following records whether a points-to solution contains any\n> > local automatic variables, not including parameters or result storage.\n> \n> Wait so does ptr_deref_may_alias_auto_p say true for parameters and result\n> storage?  Because from the commit message it seems to me it does *not*, but\n> (see bellow) ...\n> \n> > \n> > \t* tree-ssa-alias.h (pt_solution::vars_contains_auto): New.\n> > \t(ptr_deref_may_alias_auto_p): Declare.\n> > \t(pt_solution_includes_auto): Likewise.\n> > \t* tree-ssa-structalias.cc (set_uids_in_ptset): Record auto\n> > \tvariables.\n> > \t(pt_solution_includes_auto): New function.\n> > \t(ipa_escaped_pt): Adjust.\n> > \t* tree-ssa-alias.cc (ptr_deref_may_alias_auto_p): New function.\n> > ---\n> >  gcc/tree-ssa-alias.cc       | 24 ++++++++++++++++++++++++\n> >  gcc/tree-ssa-alias.h        |  4 ++++\n> >  gcc/tree-ssa-structalias.cc | 30 +++++++++++++++++++++++++++++-\n> >  3 files changed, 57 insertions(+), 1 deletion(-)\n> > \n> > diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc\n> > index f662924b07f..e884d7e7012 100644\n> > --- a/gcc/tree-ssa-alias.cc\n> > +++ b/gcc/tree-ssa-alias.cc\n> > @@ -238,6 +238,30 @@ ptr_deref_may_alias_global_p (tree ptr, bool escaped_local_p)\n> >    return pt_solution_includes_global (&pi->pt, escaped_local_p);\n> >  }\n> >  \n> > +/* Return true, if dereferencing PTR may alias with a local automatic\n> > +   variable.  */\n> > +\n> > +bool\n> > +ptr_deref_may_alias_auto_p (tree ptr)\n> > +{\n> > +  struct ptr_info_def *pi;\n> > +\n> > +  /* If we end up with a pointer constant here that may point\n> > +     to local stack memory.  */\n> > +  if (TREE_CODE (ptr) != SSA_NAME)\n> > +    return true;\n> > +\n> > +  pi = SSA_NAME_PTR_INFO (ptr);\n> > +\n> > +  /* If we do not have points-to information for this variable,\n> > +     we have to punt.  */\n> > +  if (!pi)\n> > +    return true;\n> > +\n> > +  return pt_solution_includes_auto (&pi->pt);\n> > +}\n> > +\n> > +\n> >  /* Return true if dereferencing PTR may alias DECL.\n> >     The caller is responsible for applying TBAA to see if PTR\n> >     may access DECL at all.  */\n> > diff --git a/gcc/tree-ssa-alias.h b/gcc/tree-ssa-alias.h\n> > index e0785c5d4bb..ccac9c539bb 100644\n> > --- a/gcc/tree-ssa-alias.h\n> > +++ b/gcc/tree-ssa-alias.h\n> > @@ -54,6 +54,8 @@ struct GTY(()) pt_solution\n> >  \n> >    /* Nonzero if the vars bitmap includes a variable included in 'nonlocal'.  */\n> >    unsigned int vars_contains_nonlocal : 1;\n> > +  /* Nonzero if the vars bitmap includes a local automatic variable.  */\n> > +  unsigned int vars_contains_auto : 1;\n> >    /* Nonzero if the vars bitmap includes a variable included in 'escaped'.  */\n> >    unsigned int vars_contains_escaped : 1;\n> >    /* Nonzero if the vars bitmap includes a anonymous heap variable that\n> > @@ -127,6 +129,7 @@ extern tree ao_ref_base_alias_ptr_type (ao_ref *);\n> >  extern bool ao_ref_alignment (ao_ref *, unsigned int *,\n> >  \t\t\t      unsigned HOST_WIDE_INT *);\n> >  extern bool ptr_deref_may_alias_global_p (tree, bool);\n> > +extern bool ptr_deref_may_alias_auto_p (tree);\n> >  extern bool ptr_derefs_may_alias_p (tree, tree);\n> >  extern bool ptrs_compare_unequal (tree, tree);\n> >  extern bool ref_may_alias_global_p (tree, bool);\n> > @@ -182,6 +185,7 @@ extern unsigned int compute_may_aliases (void);\n> >  extern bool pt_solution_empty_p (const pt_solution *);\n> >  extern bool pt_solution_singleton_or_null_p (struct pt_solution *, unsigned *);\n> >  extern bool pt_solution_includes_global (struct pt_solution *, bool);\n> > +extern bool pt_solution_includes_auto (struct pt_solution *);\n> >  extern bool pt_solution_includes (struct pt_solution *, const_tree);\n> >  extern bool pt_solution_includes_const_pool (struct pt_solution *);\n> >  extern bool pt_solutions_intersect (struct pt_solution *, struct pt_solution *);\n> > diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc\n> > index e4a185d0f84..806a10d980b 100644\n> > --- a/gcc/tree-ssa-structalias.cc\n> > +++ b/gcc/tree-ssa-structalias.cc\n> > @@ -801,6 +801,13 @@ set_uids_in_ptset (bitmap into, bitmap from, struct pt_solution *pt,\n> >  \t\t  && ! auto_var_in_fn_p (vi->decl, fndecl)))\n> >  \t    pt->vars_contains_nonlocal = true;\n> >  \n> > +\t  /* If the variable is an automatic in the local stack frame, record\n> > +\t     that.  Note this includes PARM_DECL and RESULT_DECL which\n> > +\t     are managed by the caller.  */\n> \n> ... from this comment it seems to me it *does*.  Just checking if I perhaps\n> found a mistake or if I just don't understand the patch.\n\nWhoops, comment typo ;)\n\n> Cheers,\n> Filip\n> \n> > +\t  if (VAR_P (vi->decl)\n\n^^^\n\n> > +\t      && auto_var_in_fn_p (vi->decl, fndecl))\n> > +\t    pt->vars_contains_auto = true;\n> > +\n> >  \t  /* If we have a variable that is interposable record that fact\n> >  \t     for pointer comparison simplification.  */\n> >  \t  if (VAR_P (vi->decl)\n> > @@ -1120,6 +1127,27 @@ pt_solution_includes_global (struct pt_solution *pt, bool escaped_local_p)\n> >    return false;\n> >  }\n> >  \n> > +/* Return true if the points-to solution *PT includes local automatic\n> > +   storage.  */\n> > +\n> > +bool\n> > +pt_solution_includes_auto (struct pt_solution *pt)\n> > +{\n> > +  if (pt->anything\n> > +      || pt->vars_contains_auto)\n> > +    return true;\n> > +\n> > +  /* 'escaped' is also a placeholder so we have to look into it.  */\n> > +  if (pt->escaped)\n> > +    return pt_solution_includes_auto (&cfun->gimple_df->escaped);\n> > +\n> > +  if (pt->ipa_escaped)\n> > +    return pt_solution_includes_auto (&ipa_escaped_pt);\n> > +\n> > +  return false;\n> > +}\n> > +\n> > +\n> >  /* Return true if the points-to solution *PT includes the variable\n> >     declaration DECL.  */\n> >  \n> > @@ -1803,7 +1831,7 @@ make_pass_build_ealias (gcc::context *ctxt)\n> >  /* IPA PTA solutions for ESCAPED.  */\n> >  struct pt_solution ipa_escaped_pt\n> >    = { true, false, false, false, false, false,\n> > -      false, false, false, false, false, NULL };\n> > +      false, false, false, false, false, false, NULL };\n> >  \n> >  \n> >  /* Execute the driver for IPA PTA.  */\n> > -- \n> > 2.51.0\n> > \n> \n>","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=icOcR/uJ;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=9UXG6AXz;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=icOcR/uJ;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=9UXG6AXz;\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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=icOcR/uJ;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=9UXG6AXz;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=icOcR/uJ;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=9UXG6AXz","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"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 4fvQPS6bChz1yDG\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 21:37:31 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 95F134BA2E1C\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 11:37:29 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id A24294BA2E04\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 11:37:00 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id 8401B6A890;\n Mon, 13 Apr 2026 11:36:59 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 95F134BA2E1C","OpenDKIM Filter v2.11.0 sourceware.org A24294BA2E04"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A24294BA2E04","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A24294BA2E04","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776080220; cv=none;\n b=a46egqij3Nv5ueRKQcTnmjNMp48iHyFRGz7XY3dqm8SHTP9FAogf/z3TxfOxkH74FPrk1iCCP2WbjHWHrXnmsQqAtnPV4aKtJVqCUjZ7jgChbme8SduPRT6o3cz0lgO2+BGxGeQjLciJpsv+3GabpxWmMnaT+vIx7lyD1ElWCGM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776080220; c=relaxed/simple;\n bh=LwXbft5o1F1RJjGhi73Tl22tJjixsdxBR9PQgk7cUg4=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=Qwdohh2Ar4tFf5Uoj5jczniLK1gMMF+SD+tNAPHJUWmZbnIqef5BKwWv3L8FdX9vZmRNisDUJEBN18jofjpQp7/DXkwraoeMD/gXyaMND2axKIkQDkq8Az+dks0YnZ0E8ciVpEam5PrziHSi9nNtArWpywECcHKKbcMZOYZkets=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776080219;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NpoZtEG8D7f6c4fJLrveoKrbKZ01/yjDHNyjKlbbIeA=;\n b=icOcR/uJfRgPOtcLhbqrLRHRd7JmdJjxMFnqkVg3znCsiz16rryJ1op9BB/VsodeHEIfur\n xHylt/0SJIdH9jBJlmMKWd1kZmp2jyUA5Emnv4Te6Oc8Wcy119P/ll/oE3zYLFIv4VuSZg\n TLzR82HB6MFmrmZ4q0ucsOT4C6DeKHU=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776080219;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NpoZtEG8D7f6c4fJLrveoKrbKZ01/yjDHNyjKlbbIeA=;\n b=9UXG6AXzUOVm917dTB2V/MkEsKo7bbmVjLXUuwqF4GM2o7WAcfPWP7ADEVV/7Yc3ora5Sm\n sUyShRdIsvANLhDQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776080219;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NpoZtEG8D7f6c4fJLrveoKrbKZ01/yjDHNyjKlbbIeA=;\n b=icOcR/uJfRgPOtcLhbqrLRHRd7JmdJjxMFnqkVg3znCsiz16rryJ1op9BB/VsodeHEIfur\n xHylt/0SJIdH9jBJlmMKWd1kZmp2jyUA5Emnv4Te6Oc8Wcy119P/ll/oE3zYLFIv4VuSZg\n TLzR82HB6MFmrmZ4q0ucsOT4C6DeKHU=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776080219;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=NpoZtEG8D7f6c4fJLrveoKrbKZ01/yjDHNyjKlbbIeA=;\n b=9UXG6AXzUOVm917dTB2V/MkEsKo7bbmVjLXUuwqF4GM2o7WAcfPWP7ADEVV/7Yc3ora5Sm\n sUyShRdIsvANLhDQ=="],"Date":"Mon, 13 Apr 2026 13:36:59 +0200 (CEST)","From":"Richard Biener <rguenther@suse.de>","To":"Filip Kastl <fkastl@suse.cz>","cc":"\"H.J. Lu\" <hjl.tools@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>,\n Uros Bizjak <ubizjak@gmail.com>, Hongtao Liu <hongtao.liu@intel.com>,\n Sam James <sam@gentoo.org>, Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","In-Reply-To":"<7nbov2w7q46jtkwyytge2h3dnvxbj4zzarw7h5mhxbbzspuub3@7jphznycm2ka>","Message-ID":"<o63so56q-p336-00r2-6562-9op0397rn881@fhfr.qr>","References":"<4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>\n <7nbov2w7q46jtkwyytge2h3dnvxbj4zzarw7h5mhxbbzspuub3@7jphznycm2ka>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","X-Spamd-Result":"default: False [-6.80 / 50.00]; REPLY(-4.00)[];\n BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[];\n NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0];\n TAGGED_RCPT(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com];\n MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[];\n RCPT_COUNT_SEVEN(0.00)[7];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n URIBL_BLOCKED(0.00)[tree-ssa-structalias.cc:url,fhfr.qr:mid,suse.de:email,murzim.nue2.suse.org:helo,tree-ssa-alias.cc:url];\n FROM_HAS_DN(0.00)[];\n FREEMAIL_CC(0.00)[gmail.com,gcc.gnu.org,intel.com,gentoo.org,googlemail.com];\n MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[];\n TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676679,"web_url":"http://patchwork.ozlabs.org/comment/3676679/","msgid":"<685p4q03-1p87-81p4-08q5-12092or2729r@fhfr.qr>","list_archive_url":null,"date":"2026-04-13T11:47:49","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Mon, 13 Apr 2026, H.J. Lu wrote:\n\n> On Mon, Apr 13, 2026 at 6:22 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> >\n> > On Mon, Apr 13, 2026 at 5:24 PM Richard Biener <rguenther@suse.de> wrote:\n> > >\n> > > On Mon, 13 Apr 2026, H.J. Lu wrote:\n> > >\n> > > > On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > >\n> > > > > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> > > > >\n> > > > > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > > > > >\n> > > > > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > > > >\n> > > > > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > > > > >\n> > > > > > ...\n> > > > > > > > >\n> > > > > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > > > > >\n> > > > > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > > > > >\n> > > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > > isn't available,\n> > > > > > > > >\n> > > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > > local variable reference.\n> > > > > > > > >\n> > > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > > base may point to stack or frame pointers.\n> > > > > > > > >\n> > > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > > unchanged.\n> > > > > > > > >\n> > > > > > > > > PR target/109780\n> > > > > > > > > PR target/109093\n> > > > > > > > > PR target/123210\n> > > > > > > > > PR target/124098\n> > > > > > > > > PR target/124165\n> > > > > > > > > PR target/124684\n> > > > > > > > > PR target/124759\n> > > > > > > > > PR target/124789\n> > > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > > (find_base_term): Remove static.\n> > > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > > (find_base_term): New prototype.\n> > > > > > > >\n> > > > > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > > > > implementation is in alias.cc\n> > > > > > >\n> > > > > > > Done.\n> > > > > > >\n> > > > > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > > > > >  {\n> > > > > > > > ...\n> > > > > > > >   /* Check RTL points-to info.  */\n> > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > >   if (!base)\n> > > > > > > > ...\n> > > > > > > >\n> > > > > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > > > > positive early out.  Thus\n> > > > > > > >\n> > > > > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > >   if (base\n> > > > > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > > >     return;\n> > > > > > >\n> > > > > > > I changed it to\n> > > > > > >\n> > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > >   if (base)\n> > > > > > >     {\n> > > > > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > > > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > >         alignment = mem_align;\n> > > > > > >       return;\n> > > > > > >     }\n> > > > >\n> > > > > That looks good.\n> > > > >\n> > > > > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > > > > rewriting\n> > > > > > > >\n> > > > > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > > > > >\n> > > > > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > > > > *)&k] ] [116]))\n> > > > > > > >\n> > > > > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > > > > >               rtx x = DECL_RTL (var);\n> > > > > > > >               if (MEM_P (x))\n> > > > > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > > > > >\n> > > > > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > > > > case might be done entirely on decl devel by using\n> > > > > > > >\n> > > > > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > > > > >       return;\n> > > > > > > >\n> > > > > > > > no need to dispatch through DECL_RTL?\n> > > > > > >\n> > > > > > > I changed it to\n> > > > > > >\n> > > > > > >      else if (decl_in_symtab_p (var))\n> > > > > > >         return;\n> > > > > > >\n> > > > > > > > and the end of the function should have the conservative fallback:\n> > > > > > > >\n> > > > > > > >   alignment = mem_align;\n> > > > > > > > }\n> > > > > > > >\n> > > > > > > > Thanks,\n> > > > > > > > Richard.\n> > > > > > > >\n> > > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > > >\n> > > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > > >\n> > > > > > > > >\n> > > > > > > >\n> > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > isn't available,\n> > > > > > >\n> > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > static/external variable reference.\n> > > > > > >\n> > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > base may point to stack or frame pointers.\n> > > > > > >\n> > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > unchanged.\n> > > > > > >\n> > > > > > > PR target/109780\n> > > > > > > PR target/109093\n> > > > > > > PR target/123210\n> > > > > > > PR target/124098\n> > > > > > > PR target/124165\n> > > > > > > PR target/124684\n> > > > > > > PR target/124759\n> > > > > > > PR target/124789\n> > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > (find_base_term): Remove static.\n> > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > * alias.h (find_base_term): New prototype.\n> > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > >\n> > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > >\n> > > > > > > --\n> > > > > > > H.J.\n> > > > > >\n> > > > > > Some updates:\n> > > > > >\n> > > > > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > > > > 2.  Use\n> > > > > >\n> > > > > >       if (TREE_CODE (var) == PARM_DECL\n> > > > > >           || TREE_CODE (var) == MEM_REF\n> > > > > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > > > > >           || decl_in_symtab_p (var))\n> > > > > >         return;\n> > > > >\n> > > > > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > > > > neither is skipping for PARM_DECL since that will also hit on\n> > > > > callee copies with larger alignment.\n> > > > >\n> > > > >    if (VAR_P (var) && decl_in_symtab_p (var))\n> > > > >      return;\n> > > > >\n> > > > > or\n> > > > >\n> > > > >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> > > > >      return;\n> > > > >\n> > > > > would be both OK (I think the latter is more to the point).\n> > > > >\n> > > > > The PARM_DECL case should be catched by find_base_term which\n> > > > > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > > > > (but not for the callee copy which should be based on\n> > > > > FRAME_POINTER_REGNUM).\n> > > > >\n> > > > > The address-space case chould be handled generally at the toplevel,\n> > > > >\n> > > > >   /* All stack is in the generic address space.  */\n> > > > >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> > > > >     return;\n> > > > >\n> > > > >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > > > > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> > > > >               (reg:V4DI 20 xmm0 [117]))\n> > > > >\n> > > > >          from gcc.target/i386/pr124098.c,\n> > > > >\n> > > > > I don't see how to easily handle this case.  GIMPLE points-to\n> > > > > info (which would be accessible through _34) does currently not\n> > > > > track a separate \"may point to (local) stack\" - that would be\n> > > > > straight-forward to add though (but it increasingly feels like\n> > > > > something to do for stage1).\n> > > >\n> > > > What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> > > > xfail it?\n> > >\n> > > Given all relevant bugs are in FIXED state right now I would suggest\n> > > to try not disrupt stage4 further but postone this cleanup to stage1\n> > > with the eventual goal to backport for 16.2?\n> > >\n> > > You can check whether the attached patch to add\n> > > ptr_deref_may_alias_auto_p works, you'd use it like ...\n> > >\n> > > > >\n> > > > >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > > > > {ref-all})s_1(D) & 4294967280B] ] [103])\n> > > > >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > > > > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> > > > >\n> > > > >          from gcc.target/i386/pr53907.c and\n> > > > >\n> > > > > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > > > > which means it's likely an incoming parameter.  I would have expected\n> > > > > that RTL PTA analysis would assign it some class, but it's\n> > > > > pretty weak PTA.  Matching it explicitly with\n> > > > >\n> > > > > if (TREE_CODE (var) == MEM_REF\n> > > > >     || TREE_CODE (var) == TARGET_MEM_REF)\n> > > > >   {\n> > > > >     tree ptr = TREE_OPERAND (var, 0);\n> > > > >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> > > > >       ptr = TREE_OPERAND (ptr, 0);\n> > >\n> > >         if (!ptr_deref_may_alias_auto_p (ptr))\n> > >           return;\n> > >\n> > > Does that resolve the testcases?\n> >\n> > No,\n> >\n> > 8697     if (!ptr_deref_may_alias_auto_p (ptr))\n> > (gdb) call debug (ptr)\n> >  <ssa_name 0x7fffe964e210\n> >     type <pointer_type 0x7fffe9825000\n> >         type <void_type 0x7fffe981df18 void VOID\n> >             align:8 warn_if_not_align:0 symtab:0 alias-set -1\n> > canonical-type 0x7fffe981df18\n> >             pointer_to_this <pointer_type 0x7fffe9825000>>\n> >         public unsigned DI\n> >         size <integer_cst 0x7fffe9802f60 constant 64>\n> >         unit-size <integer_cst 0x7fffe9802f78 constant 8>\n> >         align:64 warn_if_not_align:0 symtab:0 alias-set -1\n> > canonical-type 0x7fffe9825000\n> >         pointer_to_this <pointer_type 0x7fffe982da80>>\n> >     visited\n> >     def_stmt _34 = (void *) ivtmp.23_37;\n> >     version:34\n> >     ptr-info 0x7fffe9650a80>\n> > (gdb) step\n> > ptr_deref_may_alias_auto_p (ptr=0x7fffe964e210)\n> >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-alias.cc:251\n> > 251   if (TREE_CODE (ptr) != SSA_NAME)\n> > (gdb) next\n> > 254   pi = SSA_NAME_PTR_INFO (ptr);\n> > (gdb)\n> > 258   if (!pi)\n> > (gdb)\n> > 261   return pt_solution_includes_auto (&pi->pt);\n> > (gdb) step\n> > pt_solution_includes_auto (pt=0x7fffe9650a80)\n> >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-structalias.cc:1136\n> > 1136   if (pt->anything\n> > (gdb) p pt->anything\n> > $1 = 1\n> > (gdb) next\n> > 1138     return true;\n> > (gdb)\n> >\n> \n> For\n> \n> ----\n> char c, d;\n> _BitInt(2048) b;\n> \n> void\n> foo (__int128, _BitInt(1024) a)\n> {\n>   b = NUM;\n>   c %= (char)(a ?: d);\n> }\n> ---\n> \n> -mavx2 -O2 fails when NUM == 0 or NUM == -1.\n\nSo this shows a missed optimization (failure to populate points-to\ninfo) for the vectorizer pass.  While that uses copy-ref-info\nin some cases it seems to miss it here.\n\nRichard.","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=UX1wkk4E;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=gfVa/woq;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=UX1wkk4E;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=gfVa/woq;\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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=UX1wkk4E;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=gfVa/woq;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=UX1wkk4E;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=gfVa/woq","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"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 4fvQf1368jz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 21:48:24 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id D9BD94BA2E29\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 11:48:21 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id 267EB4BA2E06\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 11:47:51 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id E97BC6A890;\n Mon, 13 Apr 2026 11:47:49 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org D9BD94BA2E29","OpenDKIM Filter v2.11.0 sourceware.org 267EB4BA2E06"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 267EB4BA2E06","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 267EB4BA2E06","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776080871; cv=none;\n b=tkBnAeDrMlCzoVbhvVVvfM/7XHRjAUIloElNYYMsv1jTXTk7QASY1tBgmj+yiRmzU97k8JaLSQ9DuSoc5X+B6yR03QVZZIcV+iJhuvfl/lTW9vy+X7Zs7/qA5i9HW88MrlETcfrbNYlAfK+QkQtWtrrxtY0XeDuk8BFx8miAq1k=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776080871; c=relaxed/simple;\n bh=f4XpcyeDcRMubL1X7UlEwJFYzvN1IMVznkkk/xumkPc=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=LX905GSNF+7cW5sT1zMCFt3Ju4D+oGFYbEXv7dz44kSWPQdBADjcI24Jjv7tGSchqqq4FyWpeUtFp7ISU4XYsgc7a5NSKFYy0gQre9liW8L+n18VLWnXzw0fbalPEt3rHps0gKEoDORCZ1Y6+CLjirGjByBFQMohbTFPmG4m6j4=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776080870;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=RPH1jKwtCqxV8W+cIuQDWw/uABigvk4O36zKoy86fOg=;\n b=UX1wkk4EokxNE2XT528Ls9WYvwDiNMg3hvISLBbnzirvnFGcc0KqO8J0NEKGAaW5t78o/3\n aBCNcUnYjF5OTuwVy8+Glp7/5Ti5rfDAhQKlYetFaVdUdrEQCTA56WP5++TszSSqeE5dM2\n c+XbwmpqmFVMJWj/wex3gYqB0Ijal3Y=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776080870;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=RPH1jKwtCqxV8W+cIuQDWw/uABigvk4O36zKoy86fOg=;\n b=gfVa/woq186W+SyN6hagHnXiaP6yG8S71+HUP9Mwam/FUHsEWifnpEw2UKgnD+k9rfryay\n za9O81DiQ6LZGhDw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776080870;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=RPH1jKwtCqxV8W+cIuQDWw/uABigvk4O36zKoy86fOg=;\n b=UX1wkk4EokxNE2XT528Ls9WYvwDiNMg3hvISLBbnzirvnFGcc0KqO8J0NEKGAaW5t78o/3\n aBCNcUnYjF5OTuwVy8+Glp7/5Ti5rfDAhQKlYetFaVdUdrEQCTA56WP5++TszSSqeE5dM2\n c+XbwmpqmFVMJWj/wex3gYqB0Ijal3Y=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776080870;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=RPH1jKwtCqxV8W+cIuQDWw/uABigvk4O36zKoy86fOg=;\n b=gfVa/woq186W+SyN6hagHnXiaP6yG8S71+HUP9Mwam/FUHsEWifnpEw2UKgnD+k9rfryay\n za9O81DiQ6LZGhDw=="],"Date":"Mon, 13 Apr 2026 13:47:49 +0200 (CEST)","From":"Richard Biener <rguenther@suse.de>","To":"\"H.J. Lu\" <hjl.tools@gmail.com>","cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","In-Reply-To":"\n <CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>","Message-ID":"<685p4q03-1p87-81p4-08q5-12092or2729r@fhfr.qr>","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAFiYyc3VgmggpbTkY0d+JcWyTALcHpMJWFt9W819VYdj=86xzg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>\n <CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/mixed;\n boundary=\"-1475677436-1396584906-1776080869=:28865\"","X-Spamd-Result":"default: False [-1.80 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000];\n CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.20)[-1.000];\n MIME_GOOD(-0.10)[multipart/mixed,text/plain];\n MISSING_XM_UA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com];\n TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ARC_NA(0.00)[];\n RCVD_COUNT_ZERO(0.00)[0]; FREEMAIL_ENVRCPT(0.00)[gmail.com];\n RCPT_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[];\n FREEMAIL_CC(0.00)[gcc.gnu.org,gmail.com,intel.com,gentoo.org,googlemail.com];\n FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[];\n TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n DBL_BLOCKED_OPENRESOLVER(0.00)[gcc.target:url, alias.cc:url, function.cc:url,\n suse.de:email]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676699,"web_url":"http://patchwork.ozlabs.org/comment/3676699/","msgid":"<7rqs2531-3r59-r8on-1520-soq92q4rn665@fhfr.qr>","list_archive_url":null,"date":"2026-04-13T12:12:20","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Mon, 13 Apr 2026, Richard Biener wrote:\n\n> On Mon, 13 Apr 2026, H.J. Lu wrote:\n> \n> > On Mon, Apr 13, 2026 at 6:22 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > >\n> > > On Mon, Apr 13, 2026 at 5:24 PM Richard Biener <rguenther@suse.de> wrote:\n> > > >\n> > > > On Mon, 13 Apr 2026, H.J. Lu wrote:\n> > > >\n> > > > > On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > >\n> > > > > > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> > > > > >\n> > > > > > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > > > > > >\n> > > > > > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > > > > >\n> > > > > > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > > > > > >\n> > > > > > > ...\n> > > > > > > > > >\n> > > > > > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > > > > > >\n> > > > > > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > > > > > >\n> > > > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > > > isn't available,\n> > > > > > > > > >\n> > > > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > > > local variable reference.\n> > > > > > > > > >\n> > > > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > > > base may point to stack or frame pointers.\n> > > > > > > > > >\n> > > > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > > > unchanged.\n> > > > > > > > > >\n> > > > > > > > > > PR target/109780\n> > > > > > > > > > PR target/109093\n> > > > > > > > > > PR target/123210\n> > > > > > > > > > PR target/124098\n> > > > > > > > > > PR target/124165\n> > > > > > > > > > PR target/124684\n> > > > > > > > > > PR target/124759\n> > > > > > > > > > PR target/124789\n> > > > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > > > (find_base_term): Remove static.\n> > > > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > > > (find_base_term): New prototype.\n> > > > > > > > >\n> > > > > > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > > > > > implementation is in alias.cc\n> > > > > > > >\n> > > > > > > > Done.\n> > > > > > > >\n> > > > > > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > > > > > >  {\n> > > > > > > > > ...\n> > > > > > > > >   /* Check RTL points-to info.  */\n> > > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > > >   if (!base)\n> > > > > > > > > ...\n> > > > > > > > >\n> > > > > > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > > > > > positive early out.  Thus\n> > > > > > > > >\n> > > > > > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > > >   if (base\n> > > > > > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > > > >     return;\n> > > > > > > >\n> > > > > > > > I changed it to\n> > > > > > > >\n> > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > >   if (base)\n> > > > > > > >     {\n> > > > > > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > > > > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > > >         alignment = mem_align;\n> > > > > > > >       return;\n> > > > > > > >     }\n> > > > > >\n> > > > > > That looks good.\n> > > > > >\n> > > > > > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > > > > > rewriting\n> > > > > > > > >\n> > > > > > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > > > > > >\n> > > > > > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > > > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > > > > > *)&k] ] [116]))\n> > > > > > > > >\n> > > > > > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > > > > > >               rtx x = DECL_RTL (var);\n> > > > > > > > >               if (MEM_P (x))\n> > > > > > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > > > > > >\n> > > > > > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > > > > > case might be done entirely on decl devel by using\n> > > > > > > > >\n> > > > > > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > > > > > >       return;\n> > > > > > > > >\n> > > > > > > > > no need to dispatch through DECL_RTL?\n> > > > > > > >\n> > > > > > > > I changed it to\n> > > > > > > >\n> > > > > > > >      else if (decl_in_symtab_p (var))\n> > > > > > > >         return;\n> > > > > > > >\n> > > > > > > > > and the end of the function should have the conservative fallback:\n> > > > > > > > >\n> > > > > > > > >   alignment = mem_align;\n> > > > > > > > > }\n> > > > > > > > >\n> > > > > > > > > Thanks,\n> > > > > > > > > Richard.\n> > > > > > > > >\n> > > > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > > > >\n> > > > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > >\n> > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > isn't available,\n> > > > > > > >\n> > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > static/external variable reference.\n> > > > > > > >\n> > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > base may point to stack or frame pointers.\n> > > > > > > >\n> > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > unchanged.\n> > > > > > > >\n> > > > > > > > PR target/109780\n> > > > > > > > PR target/109093\n> > > > > > > > PR target/123210\n> > > > > > > > PR target/124098\n> > > > > > > > PR target/124165\n> > > > > > > > PR target/124684\n> > > > > > > > PR target/124759\n> > > > > > > > PR target/124789\n> > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > (find_base_term): Remove static.\n> > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > * alias.h (find_base_term): New prototype.\n> > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > >\n> > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > >\n> > > > > > > > --\n> > > > > > > > H.J.\n> > > > > > >\n> > > > > > > Some updates:\n> > > > > > >\n> > > > > > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > > > > > 2.  Use\n> > > > > > >\n> > > > > > >       if (TREE_CODE (var) == PARM_DECL\n> > > > > > >           || TREE_CODE (var) == MEM_REF\n> > > > > > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > > > > > >           || decl_in_symtab_p (var))\n> > > > > > >         return;\n> > > > > >\n> > > > > > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > > > > > neither is skipping for PARM_DECL since that will also hit on\n> > > > > > callee copies with larger alignment.\n> > > > > >\n> > > > > >    if (VAR_P (var) && decl_in_symtab_p (var))\n> > > > > >      return;\n> > > > > >\n> > > > > > or\n> > > > > >\n> > > > > >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> > > > > >      return;\n> > > > > >\n> > > > > > would be both OK (I think the latter is more to the point).\n> > > > > >\n> > > > > > The PARM_DECL case should be catched by find_base_term which\n> > > > > > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > > > > > (but not for the callee copy which should be based on\n> > > > > > FRAME_POINTER_REGNUM).\n> > > > > >\n> > > > > > The address-space case chould be handled generally at the toplevel,\n> > > > > >\n> > > > > >   /* All stack is in the generic address space.  */\n> > > > > >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> > > > > >     return;\n> > > > > >\n> > > > > >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > > > > > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> > > > > >               (reg:V4DI 20 xmm0 [117]))\n> > > > > >\n> > > > > >          from gcc.target/i386/pr124098.c,\n> > > > > >\n> > > > > > I don't see how to easily handle this case.  GIMPLE points-to\n> > > > > > info (which would be accessible through _34) does currently not\n> > > > > > track a separate \"may point to (local) stack\" - that would be\n> > > > > > straight-forward to add though (but it increasingly feels like\n> > > > > > something to do for stage1).\n> > > > >\n> > > > > What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> > > > > xfail it?\n> > > >\n> > > > Given all relevant bugs are in FIXED state right now I would suggest\n> > > > to try not disrupt stage4 further but postone this cleanup to stage1\n> > > > with the eventual goal to backport for 16.2?\n> > > >\n> > > > You can check whether the attached patch to add\n> > > > ptr_deref_may_alias_auto_p works, you'd use it like ...\n> > > >\n> > > > > >\n> > > > > >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > > > > > {ref-all})s_1(D) & 4294967280B] ] [103])\n> > > > > >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > > > > > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> > > > > >\n> > > > > >          from gcc.target/i386/pr53907.c and\n> > > > > >\n> > > > > > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > > > > > which means it's likely an incoming parameter.  I would have expected\n> > > > > > that RTL PTA analysis would assign it some class, but it's\n> > > > > > pretty weak PTA.  Matching it explicitly with\n> > > > > >\n> > > > > > if (TREE_CODE (var) == MEM_REF\n> > > > > >     || TREE_CODE (var) == TARGET_MEM_REF)\n> > > > > >   {\n> > > > > >     tree ptr = TREE_OPERAND (var, 0);\n> > > > > >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> > > > > >       ptr = TREE_OPERAND (ptr, 0);\n> > > >\n> > > >         if (!ptr_deref_may_alias_auto_p (ptr))\n> > > >           return;\n> > > >\n> > > > Does that resolve the testcases?\n> > >\n> > > No,\n> > >\n> > > 8697     if (!ptr_deref_may_alias_auto_p (ptr))\n> > > (gdb) call debug (ptr)\n> > >  <ssa_name 0x7fffe964e210\n> > >     type <pointer_type 0x7fffe9825000\n> > >         type <void_type 0x7fffe981df18 void VOID\n> > >             align:8 warn_if_not_align:0 symtab:0 alias-set -1\n> > > canonical-type 0x7fffe981df18\n> > >             pointer_to_this <pointer_type 0x7fffe9825000>>\n> > >         public unsigned DI\n> > >         size <integer_cst 0x7fffe9802f60 constant 64>\n> > >         unit-size <integer_cst 0x7fffe9802f78 constant 8>\n> > >         align:64 warn_if_not_align:0 symtab:0 alias-set -1\n> > > canonical-type 0x7fffe9825000\n> > >         pointer_to_this <pointer_type 0x7fffe982da80>>\n> > >     visited\n> > >     def_stmt _34 = (void *) ivtmp.23_37;\n> > >     version:34\n> > >     ptr-info 0x7fffe9650a80>\n> > > (gdb) step\n> > > ptr_deref_may_alias_auto_p (ptr=0x7fffe964e210)\n> > >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-alias.cc:251\n> > > 251   if (TREE_CODE (ptr) != SSA_NAME)\n> > > (gdb) next\n> > > 254   pi = SSA_NAME_PTR_INFO (ptr);\n> > > (gdb)\n> > > 258   if (!pi)\n> > > (gdb)\n> > > 261   return pt_solution_includes_auto (&pi->pt);\n> > > (gdb) step\n> > > pt_solution_includes_auto (pt=0x7fffe9650a80)\n> > >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-structalias.cc:1136\n> > > 1136   if (pt->anything\n> > > (gdb) p pt->anything\n> > > $1 = 1\n> > > (gdb) next\n> > > 1138     return true;\n> > > (gdb)\n> > >\n> > \n> > For\n> > \n> > ----\n> > char c, d;\n> > _BitInt(2048) b;\n> > \n> > void\n> > foo (__int128, _BitInt(1024) a)\n> > {\n> >   b = NUM;\n> >   c %= (char)(a ?: d);\n> > }\n> > ---\n> > \n> > -mavx2 -O2 fails when NUM == 0 or NUM == -1.\n> \n> So this shows a missed optimization (failure to populate points-to\n> info) for the vectorizer pass.  While that uses copy-ref-info\n> in some cases it seems to miss it here.\n\nThe attached should fix this.\n\nRichard.\n\n> Richard.","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=fwhZlIUR;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=KdMhXKGD;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=UwNQ/BEa;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=C9JWmysn;\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=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=fwhZlIUR;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=KdMhXKGD;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=UwNQ/BEa;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=C9JWmysn","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.131","smtp-out2.suse.de;\n\tnone"],"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 4fvRBS0plzz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 22:13:01 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 1844E4BA2E07\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 12:12:54 +0000 (GMT)","from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])\n by sourceware.org (Postfix) with ESMTPS id 03F5C4BA2E06\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 12:12:22 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out2.suse.de (Postfix) with ESMTPS id D70875BD09;\n Mon, 13 Apr 2026 12:12:20 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 1844E4BA2E07","OpenDKIM Filter v2.11.0 sourceware.org 03F5C4BA2E06"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 03F5C4BA2E06","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 03F5C4BA2E06","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776082342; cv=none;\n b=h8Oow91L2GDglJiItQWsN5mO4e6yUf/czKe7aiYzuAIIN/YsHmNa6KCDYtBkyWUCHBdF4p1lqfeK69McEOIxLMPM6fIS4UUUV5skwRoN7trgECSfDZOCfgZ3jFtugt5SENkGIZCzQPFX9bPatbLIT7vvVqJ1GTl+NZ5eIQ4DSoE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776082342; c=relaxed/simple;\n bh=Pl45pTkXRy/NYqypEzPbaPE6WCe9hCDRvoNi5PNRWMg=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=DbpKaB7gIr3vUeiG2FJbXt4gor3sNuk0FL0YBOzgHAGGETxz5kakuZ+qI/sqqOwngEZc0Ktml8OCGNni3HYs3e9TnYTJ02Ayo56X7E50y0+t0R07+cvTF/bhH/dDZ1hE4CmoNd6tP/ObcizmIqvkMwlgWc/X0VSnl9crPZg1jPM=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776082341;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=AROusJbtxljx165blPBE0EKfPNbyKx1tc0rudx18v7s=;\n b=fwhZlIURmedWUjyorkaOiiJ2PwQZubseAIByJfapymx35vfAk9cxBioBFjO1CrRdkZNeT2\n OQhCe4nLxlLgc0p1jzInNZB5HCAT6/fHRTUtznQkP9XQzU7o9VLCwErOp5tGomsoqUe7Rz\n +rL+qFx1Z1BKI67bzkf33ZcupUdNgzc=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776082341;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=AROusJbtxljx165blPBE0EKfPNbyKx1tc0rudx18v7s=;\n b=KdMhXKGDjsXTVOILb7p4yZTzEHKJ8TdTazTkoRGeI65YW7rbwsgK5XcDYw2f++YNhpoBx2\n /3TK+Q0iLx6lAwAQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776082340;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=AROusJbtxljx165blPBE0EKfPNbyKx1tc0rudx18v7s=;\n b=UwNQ/BEau9gwwXd0asK/nhTZsf37Mj2bjAr3xOMhrINxpKJY+x075Y9v1Pv5u83ryck93t\n 1kV1tukWcpFgMUS3qULzSljvn0CbxGBUQEVsVg20Ena/Z8n3FeDgTTHX5yjeLbfriHguUA\n 9vsHcSHf93avc9yZmIPu8JVeD+kYLTM=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776082340;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=AROusJbtxljx165blPBE0EKfPNbyKx1tc0rudx18v7s=;\n b=C9JWmysnu/5DQvqlo/0ka3XnlGBt1ZeyrQARSqDQQSqWzzUNNxjm3/9iTUjmjKkGOy2TF6\n T2Iq1i/MZVh2grCg=="],"Date":"Mon, 13 Apr 2026 14:12:20 +0200 (CEST)","From":"Richard Biener <rguenther@suse.de>","To":"\"H.J. Lu\" <hjl.tools@gmail.com>","cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","In-Reply-To":"<685p4q03-1p87-81p4-08q5-12092or2729r@fhfr.qr>","Message-ID":"<7rqs2531-3r59-r8on-1520-soq92q4rn665@fhfr.qr>","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>\n <CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>\n <685p4q03-1p87-81p4-08q5-12092or2729r@fhfr.qr>","MIME-Version":"1.0","Content-Type":"multipart/mixed;\n boundary=\"-1475677436-850629179-1776082340=:28865\"","X-Spamd-Result":"default: False [-1.70 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000];\n MIME_BASE64_TEXT_BOGUS(1.00)[];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[];\n MIME_GOOD(-0.10)[multipart/mixed,text/plain];\n TAGGED_RCPT(0.00)[]; RCVD_COUNT_ZERO(0.00)[0];\n FUZZY_RATELIMITED(0.00)[rspamd.com]; MISSING_XM_UA(0.00)[];\n ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+];\n FREEMAIL_TO(0.00)[gmail.com];\n FREEMAIL_ENVRCPT(0.00)[gmail.com];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n FROM_HAS_DN(0.00)[];\n FREEMAIL_CC(0.00)[gcc.gnu.org,gmail.com,intel.com,gentoo.org,googlemail.com];\n RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[];\n TO_MATCH_ENVRCPT_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[fhfr.qr:mid,suse.de:email,gnu.org:email];\n TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3676709,"web_url":"http://patchwork.ozlabs.org/comment/3676709/","msgid":"<CAMe9rOpbhxWrwXcsRiQC594-83oAQHw5ESdZsWT9R=_jcAz-NQ@mail.gmail.com>","list_archive_url":null,"date":"2026-04-13T12:27:02","subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Mon, Apr 13, 2026 at 8:12 PM Richard Biener <rguenther@suse.de> wrote:\n>\n> On Mon, 13 Apr 2026, Richard Biener wrote:\n>\n> > On Mon, 13 Apr 2026, H.J. Lu wrote:\n> >\n> > > On Mon, Apr 13, 2026 at 6:22 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > >\n> > > > On Mon, Apr 13, 2026 at 5:24 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > >\n> > > > > On Mon, 13 Apr 2026, H.J. Lu wrote:\n> > > > >\n> > > > > > On Mon, Apr 13, 2026 at 4:17 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > > >\n> > > > > > > On Sun, 12 Apr 2026, H.J. Lu wrote:\n> > > > > > >\n> > > > > > > > On Sat, Apr 11, 2026 at 3:06 PM H.J. Lu <hjl.tools@gmail.com> wrote:\n> > > > > > > > >\n> > > > > > > > > On Fri, Apr 10, 2026 at 7:29 PM Richard Biener <rguenther@suse.de> wrote:\n> > > > > > > > > >\n> > > > > > > > > > On Fri, 10 Apr 2026, H.J. Lu wrote:\n> > > > > > > > > >\n> > > > > > > > ...\n> > > > > > > > > > >\n> > > > > > > > > > > Revert changes in ix86_find_max_used_stack_alignment\n> > > > > > > > > > >\n> > > > > > > > > > > 7b39d7b3b84 Correct x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > > c8a84242e4b Update x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > > f511bf93f94 x86: Call ix86_access_stack_p only for larger alignment\n> > > > > > > > > > > a7cce1afee8 x86: Call ix86_access_stack_p only with symbolic constant load\n> > > > > > > > > > > b54533a2863 x86: Update stack alignment only if stack is used\n> > > > > > > > > > > b9ea3b2ef98 x86: Properly find the maximum stack slot alignment\n> > > > > > > > > > >\n> > > > > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > > > > isn't available,\n> > > > > > > > > > >\n> > > > > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > > > > local variable reference.\n> > > > > > > > > > >\n> > > > > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > > > > base may point to stack or frame pointers.\n> > > > > > > > > > >\n> > > > > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > > > > unchanged.\n> > > > > > > > > > >\n> > > > > > > > > > > PR target/109780\n> > > > > > > > > > > PR target/109093\n> > > > > > > > > > > PR target/123210\n> > > > > > > > > > > PR target/124098\n> > > > > > > > > > > PR target/124165\n> > > > > > > > > > > PR target/124684\n> > > > > > > > > > > PR target/124759\n> > > > > > > > > > > PR target/124789\n> > > > > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > > > > (find_base_term): Remove static.\n> > > > > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > > > > (find_base_term): New prototype.\n> > > > > > > > > >\n> > > > > > > > > > Please put the find_base_term declaration into alias.h given the\n> > > > > > > > > > implementation is in alias.cc\n> > > > > > > > >\n> > > > > > > > > Done.\n> > > > > > > > >\n> > > > > > > > > > +ix86_update_stack_alignment_2 (const_rtx op, unsigned int &alignment)\n> > > > > > > > > >  {\n> > > > > > > > > > ...\n> > > > > > > > > >   /* Check RTL points-to info.  */\n> > > > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > > > >   if (!base)\n> > > > > > > > > > ...\n> > > > > > > > > >\n> > > > > > > > > > I think it's better to use RTL points-to like the rest - as\n> > > > > > > > > > positive early out.  Thus\n> > > > > > > > > >\n> > > > > > > > > >   /* Skip if RTL points-to says OP cannot access the stack.  */\n> > > > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > > > >   if (base\n> > > > > > > > > >       && base != static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > > > > >       && base != static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > > > > >     return;\n> > > > > > > > >\n> > > > > > > > > I changed it to\n> > > > > > > > >\n> > > > > > > > >   rtx base = find_base_term (XEXP (op, 0));\n> > > > > > > > >   if (base)\n> > > > > > > > >     {\n> > > > > > > > >       /* Update ALIGNMENT if RTL points-to says OP accesses stack.  */\n> > > > > > > > >       if (base == static_reg_base_value[STACK_POINTER_REGNUM]\n> > > > > > > > >           || base == static_reg_base_value[FRAME_POINTER_REGNUM])\n> > > > > > > > >         alignment = mem_align;\n> > > > > > > > >       return;\n> > > > > > > > >     }\n> > > > > > >\n> > > > > > > That looks good.\n> > > > > > >\n> > > > > > > > > > and then continue with the code you have in if (!base) unconditionally,\n> > > > > > > > > > rewriting\n> > > > > > > > > >\n> > > > > > > > > >               /* Handle the case that OP is a stack memory operand in\n> > > > > > > > > >\n> > > > > > > > > >                  (set (mem/c:V16QI (reg/f:DI 1 dx [114]) [0 MEM\n> > > > > > > > > > <char[1:80]> [(void *)&k]+0 S16 A128])\n> > > > > > > > > >                       (reg:V16QI 21 xmm1 [orig:116 MEM <char[1:80]> [(void\n> > > > > > > > > > *)&k] ] [116]))\n> > > > > > > > > >\n> > > > > > > > > >                  from gcc.target/i386/pr109093-1.c.  */\n> > > > > > > > > >               rtx x = DECL_RTL (var);\n> > > > > > > > > >               if (MEM_P (x))\n> > > > > > > > > >                 base = find_base_term (XEXP (x, 0));\n> > > > > > > > > >\n> > > > > > > > > > to be the same \"positive\" check.  But then I think the above\n> > > > > > > > > > case might be done entirely on decl devel by using\n> > > > > > > > > >\n> > > > > > > > > >     if (auto_var_in_fn (var, current_function_decl))\n> > > > > > > > > >       return;\n> > > > > > > > > >\n> > > > > > > > > > no need to dispatch through DECL_RTL?\n> > > > > > > > >\n> > > > > > > > > I changed it to\n> > > > > > > > >\n> > > > > > > > >      else if (decl_in_symtab_p (var))\n> > > > > > > > >         return;\n> > > > > > > > >\n> > > > > > > > > > and the end of the function should have the conservative fallback:\n> > > > > > > > > >\n> > > > > > > > > >   alignment = mem_align;\n> > > > > > > > > > }\n> > > > > > > > > >\n> > > > > > > > > > Thanks,\n> > > > > > > > > > Richard.\n> > > > > > > > > >\n> > > > > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > > > > >\n> > > > > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > Rewrite ix86_find_max_used_stack_alignment based on RTL points-to info\n> > > > > > > > > with find_base_term and static_reg_base_value.  If RTL points-to info\n> > > > > > > > > isn't available,\n> > > > > > > > >\n> > > > > > > > > 1. Use ix86_decompose_address to check for symbolic displacement.\n> > > > > > > > > 2. Check MEM_EXPR for stack argument reference, memory reference and\n> > > > > > > > > static/external variable reference.\n> > > > > > > > >\n> > > > > > > > > Update the maximum stack slot alignment from memory alignment only if its\n> > > > > > > > > base may point to stack or frame pointers.\n> > > > > > > > >\n> > > > > > > > > The compile times of PR target/124165 and PR target/124684 test are\n> > > > > > > > > unchanged.\n> > > > > > > > >\n> > > > > > > > > PR target/109780\n> > > > > > > > > PR target/109093\n> > > > > > > > > PR target/123210\n> > > > > > > > > PR target/124098\n> > > > > > > > > PR target/124165\n> > > > > > > > > PR target/124684\n> > > > > > > > > PR target/124759\n> > > > > > > > > PR target/124789\n> > > > > > > > > * alias.cc (static_reg_base_value): Moved to rtl.h.\n> > > > > > > > > (find_base_term): Remove static.\n> > > > > > > > > * function.cc (thread_prologue_and_epilogue_insns): Call\n> > > > > > > > > init_alias_analysis and end_alias_analysis.\n> > > > > > > > > * rtl.h (static_reg_base_value): Moved from alias.cc.\n> > > > > > > > > * alias.h (find_base_term): New prototype.\n> > > > > > > > > * config/i386/i386.cc (stack_access_data): Removed.\n> > > > > > > > > (ix86_find_all_reg_uses_1): Likewise.\n> > > > > > > > > (ix86_find_all_reg_uses): Likewise.\n> > > > > > > > > (ix86_access_stack_p): Likewise.\n> > > > > > > > > (ix86_need_alignment_p_2): Likewise.\n> > > > > > > > > (ix86_need_alignment_p_1): Likewise.\n> > > > > > > > > (ix86_need_alignment_p): Likewise.\n> > > > > > > > > (ix86_update_stack_alignment_2): New function.\n> > > > > > > > > (ix86_update_stack_alignment_1): Likewise.\n> > > > > > > > > (ix86_update_stack_alignment): Rewrite.\n> > > > > > > > > (ix86_find_max_used_stack_alignment): If check_stack_slot is\n> > > > > > > > > true, call ix86_update_stack_alignment on each INSN.\n> > > > > > > > >\n> > > > > > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>\n> > > > > > > > > Co-Authored-By: Richard Biener <rguenther@suse.de>\n> > > > > > > > >\n> > > > > > > > > --\n> > > > > > > > > H.J.\n> > > > > > > >\n> > > > > > > > Some updates:\n> > > > > > > >\n> > > > > > > > 1.  Replace XEXP (op, 0) with x which was set to XEXP (op, 0) earlier.\n> > > > > > > > 2.  Use\n> > > > > > > >\n> > > > > > > >       if (TREE_CODE (var) == PARM_DECL\n> > > > > > > >           || TREE_CODE (var) == MEM_REF\n> > > > > > > >           || TREE_CODE (var) == TARGET_MEM_REF\n> > > > > > > >           || decl_in_symtab_p (var))\n> > > > > > > >         return;\n> > > > > > >\n> > > > > > > Skipping for all MEM_REF/TARGET_MEM_REF is not conservatively correct,\n> > > > > > > neither is skipping for PARM_DECL since that will also hit on\n> > > > > > > callee copies with larger alignment.\n> > > > > > >\n> > > > > > >    if (VAR_P (var) && decl_in_symtab_p (var))\n> > > > > > >      return;\n> > > > > > >\n> > > > > > > or\n> > > > > > >\n> > > > > > >    if (VAR_P (var) && !auto_var_in_fn (var, current_function_decl))\n> > > > > > >      return;\n> > > > > > >\n> > > > > > > would be both OK (I think the latter is more to the point).\n> > > > > > >\n> > > > > > > The PARM_DECL case should be catched by find_base_term which\n> > > > > > > should return static_reg_base_value[ARG_POINTER_REGNUM] for them\n> > > > > > > (but not for the callee copy which should be based on\n> > > > > > > FRAME_POINTER_REGNUM).\n> > > > > > >\n> > > > > > > The address-space case chould be handled generally at the toplevel,\n> > > > > > >\n> > > > > > >   /* All stack is in the generic address space.  */\n> > > > > > >   if (MEM_ADDR_SPACE (op) != ADDR_SPACE_GENERIC)\n> > > > > > >     return;\n> > > > > > >\n> > > > > > >          (set (mem:V4DI (reg:DI 0 ax [orig:112 ivtmp.23 ] [112]) [1 MEM\n> > > > > > > <vector(4) unsigned long> [(_BitInt(2048) *)_34]+0 S32 A256])\n> > > > > > >               (reg:V4DI 20 xmm0 [117]))\n> > > > > > >\n> > > > > > >          from gcc.target/i386/pr124098.c,\n> > > > > > >\n> > > > > > > I don't see how to easily handle this case.  GIMPLE points-to\n> > > > > > > info (which would be accessible through _34) does currently not\n> > > > > > > track a separate \"may point to (local) stack\" - that would be\n> > > > > > > straight-forward to add though (but it increasingly feels like\n> > > > > > > something to do for stage1).\n> > > > > >\n> > > > > > What should we do for  gcc.target/i386/pr124098.c in the meantime?\n> > > > > > xfail it?\n> > > > >\n> > > > > Given all relevant bugs are in FIXED state right now I would suggest\n> > > > > to try not disrupt stage4 further but postone this cleanup to stage1\n> > > > > with the eventual goal to backport for 16.2?\n> > > > >\n> > > > > You can check whether the attached patch to add\n> > > > > ptr_deref_may_alias_auto_p works, you'd use it like ...\n> > > > >\n> > > > > > >\n> > > > > > >          (set (reg:V2DI 20 xmm0 [orig:103 MEM[(const __m128i *\n> > > > > > > {ref-all})s_1(D) & 4294967280B] ] [103])\n> > > > > > >               (mem:V2DI (reg:SI 0 ax [102]) [0 MEM[(const __m128i *\n> > > > > > > {ref-all})s_1(D) & 4294967280B]+0 S16 A128]))\n> > > > > > >\n> > > > > > >          from gcc.target/i386/pr53907.c and\n> > > > > > >\n> > > > > > > this shows a s_1(D) based address (huh, the & is unexpected there),\n> > > > > > > which means it's likely an incoming parameter.  I would have expected\n> > > > > > > that RTL PTA analysis would assign it some class, but it's\n> > > > > > > pretty weak PTA.  Matching it explicitly with\n> > > > > > >\n> > > > > > > if (TREE_CODE (var) == MEM_REF\n> > > > > > >     || TREE_CODE (var) == TARGET_MEM_REF)\n> > > > > > >   {\n> > > > > > >     tree ptr = TREE_OPERAND (var, 0);\n> > > > > > >     if (TREE_CODE (ptr) == BIT_AND_EXPR)\n> > > > > > >       ptr = TREE_OPERAND (ptr, 0);\n> > > > >\n> > > > >         if (!ptr_deref_may_alias_auto_p (ptr))\n> > > > >           return;\n> > > > >\n> > > > > Does that resolve the testcases?\n> > > >\n> > > > No,\n> > > >\n> > > > 8697     if (!ptr_deref_may_alias_auto_p (ptr))\n> > > > (gdb) call debug (ptr)\n> > > >  <ssa_name 0x7fffe964e210\n> > > >     type <pointer_type 0x7fffe9825000\n> > > >         type <void_type 0x7fffe981df18 void VOID\n> > > >             align:8 warn_if_not_align:0 symtab:0 alias-set -1\n> > > > canonical-type 0x7fffe981df18\n> > > >             pointer_to_this <pointer_type 0x7fffe9825000>>\n> > > >         public unsigned DI\n> > > >         size <integer_cst 0x7fffe9802f60 constant 64>\n> > > >         unit-size <integer_cst 0x7fffe9802f78 constant 8>\n> > > >         align:64 warn_if_not_align:0 symtab:0 alias-set -1\n> > > > canonical-type 0x7fffe9825000\n> > > >         pointer_to_this <pointer_type 0x7fffe982da80>>\n> > > >     visited\n> > > >     def_stmt _34 = (void *) ivtmp.23_37;\n> > > >     version:34\n> > > >     ptr-info 0x7fffe9650a80>\n> > > > (gdb) step\n> > > > ptr_deref_may_alias_auto_p (ptr=0x7fffe964e210)\n> > > >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-alias.cc:251\n> > > > 251   if (TREE_CODE (ptr) != SSA_NAME)\n> > > > (gdb) next\n> > > > 254   pi = SSA_NAME_PTR_INFO (ptr);\n> > > > (gdb)\n> > > > 258   if (!pi)\n> > > > (gdb)\n> > > > 261   return pt_solution_includes_auto (&pi->pt);\n> > > > (gdb) step\n> > > > pt_solution_includes_auto (pt=0x7fffe9650a80)\n> > > >     at /export/gnu/import/git/gitlab/x86-gcc/gcc/tree-ssa-structalias.cc:1136\n> > > > 1136   if (pt->anything\n> > > > (gdb) p pt->anything\n> > > > $1 = 1\n> > > > (gdb) next\n> > > > 1138     return true;\n> > > > (gdb)\n> > > >\n> > >\n> > > For\n> > >\n> > > ----\n> > > char c, d;\n> > > _BitInt(2048) b;\n> > >\n> > > void\n> > > foo (__int128, _BitInt(1024) a)\n> > > {\n> > >   b = NUM;\n> > >   c %= (char)(a ?: d);\n> > > }\n> > > ---\n> > >\n> > > -mavx2 -O2 fails when NUM == 0 or NUM == -1.\n> >\n> > So this shows a missed optimization (failure to populate points-to\n> > info) for the vectorizer pass.  While that uses copy-ref-info\n> > in some cases it seems to miss it here.\n>\n> The attached should fix this.\n>\n\nYes, it works.  I am testing:\n\n  tree mem_expr = MEM_EXPR (op);\n  if (mem_expr)\n    {\n      tree var = get_base_address (mem_expr);\n\n      if (TREE_CODE (var) == MEM_REF\n          || TREE_CODE (var) == TARGET_MEM_REF)\n        {\n           tree ptr = TREE_OPERAND (var, 0);\n           if (TREE_CODE (ptr) == BIT_AND_EXPR)\n             ptr = TREE_OPERAND (ptr, 0);\n\n            if (!ptr_deref_may_alias_auto_p (ptr)\n                || (TREE_CODE (ptr) == SSA_NAME\n                    && SSA_NAME_IS_DEFAULT_DEF (ptr)\n                    && TREE_CODE (SSA_NAME_VAR (ptr)) == PARM_DECL))\n             return;\n        }\n      else if (VAR_P (var)\n               && !auto_var_in_fn_p (var, current_function_decl))\n        return;\n    }\n\n  alignment = mem_align;","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=H2ykCOrA;\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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=H2ykCOrA","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.216.46"],"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 4fvRWw17MPz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 22:28:12 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 515A94BA2E25\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 12:28:10 +0000 (GMT)","from mail-pj1-f46.google.com (mail-pj1-f46.google.com\n [209.85.216.46])\n by sourceware.org (Postfix) with ESMTPS id 3402D4BA2E06\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 12:27:41 +0000 (GMT)","by mail-pj1-f46.google.com with SMTP id\n 98e67ed59e1d1-35da9c0c007so3951855a91.2\n for <gcc-patches@gcc.gnu.org>; Mon, 13 Apr 2026 05:27:41 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 515A94BA2E25","OpenDKIM Filter v2.11.0 sourceware.org 3402D4BA2E06"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 3402D4BA2E06","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 3402D4BA2E06","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776083261; cv=pass;\n b=RdoYX8reLFXhNV5wb2wj+EFhD7Dt1sRF4sFGcT8yN+jCVM91lpaQfWMAmGn0mjOaOPPKzGHqYo3E2OMnRBNSDT0k/P+1D9waJJ9lbi2H/kO3eypY3KVBZcIdtVOntRM8m9yFSRWjaPenTjqtGQv2i8UrU99AU1wYbB2e8CDimsQ=","i=1; a=rsa-sha256; t=1776083260; cv=none;\n d=google.com; s=arc-20240605;\n b=AqxCDdeTLjz9TZ+MlZL3GF4tbKMEqLbRai+lSyYr5TM3qOvjRb0PqrzFPvtG837cv3\n +gxg4gaODGAoG6BtqnNXmLsYUcuez47fVkc286nk4QUkEUG/b9qrL1Re1MCNNuy7rWoR\n 7quQBlWMVzyX/wEe4a99CZbGmc6/x9ket9BTNkWKElE8eqdLSUMU8yHI09FgU7Nudsxs\n FTdSVeue3yV89tKZRqkF0cklOo1+0mTYcp9RFw1T3OQIOVM770C5STmFgh5ACUHJZPjD\n wFjw4OBfxIxDMv33if4hhVaSRpK7RDoiUmMXtqV7G5wnkkFUBziVzNk+FY8Xb4ZuGlbR\n ZEUg=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776083261; c=relaxed/simple;\n bh=smRYU6C3Wxf6/RlJY5oRcCAbQPqqJmBbwGTcym2By9I=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=Jisjou/gWJQNUaMrG+BSw6EYM4k+1R7ap0MwgqFQO9H20NuGBpgc/ki0qnL3DJ83keP5Dae+w5uRTmiLUVU7uF5MlQLu8A7NgXNlJ6Gpo5IvvRSmd/KKQKiRAlqTKFt2bc7BQr7tYx4D/VD3ZE0iecFikw4X36QPvqX+eP0Ldes=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=1K7+/aamV/Qbn9cfrcBDAGi9WPVSXQAKXBHUJZJj3kk=;\n fh=sFFq4wvy7UcSKlgT6RiqXOQFQjorSTnVHLzf7/o8kz4=;\n b=H8Vk0vmNQD2PLzpCagb5qW3V+QMrt7YwARlwTp06KjjsGnTUssEbnw3c7KLzQfysGF\n 4Iwt18InCXa0A6n3O+cKZFxzGBqmZUfC3Y4eQnpC2RiSHlFu21E+bgy9GXqk+wa3Bmgu\n RQ9s5MYyF6MmL5Ci1OHGhlq+WD9XJEI3kahy+MymwhiFCbWWG+rGVB6+KE4Bt30m2n8w\n 3iz5VudLmWaqIhxbmoIGhku1LFh/o6Lq8mGviXXraOxgdda1CcqIo7PnsgGYdcd5F7rO\n /R3tQSaAcNRXQQDZTrETKRipWSZyDY0t5OaOL0joZ7vH7JTx9dJBqI9VrQqByjBT67DX\n SE0A==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776083260; x=1776688060; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=1K7+/aamV/Qbn9cfrcBDAGi9WPVSXQAKXBHUJZJj3kk=;\n b=H2ykCOrAzPsxy1qbnj+T0S74vj6PRn92n2Br+Cqh87a33jCwHqpTlhu/c0I+TbGZvU\n s84E8rHtB1tnKZsMlK7dsVqlobnleuGRM8PptsoL3ityVtNq5uDU8V8Ak+eqf5H3nuiz\n nbvXQ2FzHYSWET/VC+PKn5QQhsQxJ/ByVNqYTLTI54QYCVCiCnSEiAbBp+2jc9W4HVTR\n yGqQc1duNbQA98oP5r4IFINAhKDIk8BbpsPQsexRjAMB8Vxl0s4VvvGHhuri/Y4KUCNV\n TL+CUrox/9zP9s4nSLgTRIZKtq9utQb5hAT6KZfkfbtqZ9dZVypLdawFZYHwqCTmXIeZ\n L2fA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776083260; x=1776688060;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=1K7+/aamV/Qbn9cfrcBDAGi9WPVSXQAKXBHUJZJj3kk=;\n b=Y96Zu7S+hlOScJLJ0M1i3bqNbFBGN4OMfSYVDE1ZDXOCW7+KOVt00lzKtyBWHepHJh\n ulG32TuQUri8ICnWUwd73/uNix8O4f7z497gdk02z+4pK6DcvgoqJWEoHhgBDNSDN0JC\n M4UDDjoFdkD+9TyXMSCxlfOn8M5l3r2dOm0lgvFupMGdZ4qOWn0/0Px2g3fG4i3VLd9T\n CbYb6BEeDkAvWGPIDRUARV2I0ry1PmZaDL5/z2kpjf/2wvon4onyYUmEsqRzdpOIb2CN\n QhrnS4tPCUuBcQwqsoHeUTBfLCQ6fgLjgwROUekAhgOYABS3iKIe+g7JBvnlHGQZXVMi\n 9RnA==","X-Gm-Message-State":"AOJu0YwBUoOOd0t1jmCOInxG+nM3CpDpuuunjkgRV7wOOYk4+2KgnHrn\n iXZlpAg+wwwj7V0FUwL7xfBdC9yB3tO2n6PQs9QwynbKSEIHpS8djntrbA4QiNg7axpAsvan3E9\n sOBjnsaYXCcondij2Gz+ihT76WVhnMbE=","X-Gm-Gg":"AeBDievUUvbylMXJihoyrScDtfyYfmtl6GgXTf+2VUaXoD339qiY4gqRJagaKr6M6v7\n rqJrNRaboTyzqV3zHeZ3Z5XYzcvtoiiy3P+KWzC9hCDUoDuv3Mo4YZEFp67viHBOV+IkYhP3ed0\n jdOHgrTqh/3gtIzYXg0pVFStF4bVcagxAr+P2tsfAmsdirg6h8LEo164cIr8XEDDUWTdSfTVXQ8\n SGW4I2Gs+IoBcRE2th75OTea7JPP2TRzIlsi/ASKVM+DnD41LuluH+qxvgy0+ld9hmLjvyWgdqG\n F7WLde8=","X-Received":"by 2002:a17:90b:3d86:b0:35c:30a8:319 with SMTP id\n 98e67ed59e1d1-35e423f41c8mr14115011a91.0.1776083259934; Mon, 13 Apr 2026\n 05:27:39 -0700 (PDT)","MIME-Version":"1.0","References":"\n <CAMe9rOqehAHY1DjMoco_vDqoPSY4-o=q=Ty6Yro9uDHOy+2CBg@mail.gmail.com>\n <CAMe9rOpioAjEe1Y-5MRm1vjaGW0DLKUpasj4_XfGb8u8-7Vc1A@mail.gmail.com>\n <4369013r-62p8-s3n6-7s47-3rss9r034304@fhfr.qr>\n <CAMe9rOqQ0MHB5FWCZM+gZZc-S=bHY5=w6D707EdsPNvLAWWLTA@mail.gmail.com>\n <16nn5044-ooro-2sos-1o7o-9rnr833no6or@fhfr.qr>\n <CAMe9rOr8BGAgU-gZsYhjrBZC7hZjNE6ys01ddNZfEXQ7yV6RRQ@mail.gmail.com>\n <39q41058-o96q-r064-5o6q-p44934n3po76@fhfr.qr>\n <CAMe9rOohcmgwZMmTsn5orrCP6rB-+1Mzx=-AQT-uS5nz192zfg@mail.gmail.com>\n <CAMe9rOrf_Gcx-o2rGvzSH3UzLE41rJ85b04oXrdU71-wvg1guQ@mail.gmail.com>\n <po75rnrp-o18o-2392-p3rs-pn6pq5ror52q@fhfr.qr>\n <CAMe9rOoXUS_YAabfyPJwRH8fxm3YcMv1tj4=5a4nHB90WW6T=A@mail.gmail.com>\n <2qqor91o-83os-9nrs-85r4-p7201984r8o7@fhfr.qr>\n <CAMe9rOqJpi1OPOhA1cJQ2eiwpv8eVeUA0BU0E5rh2VhAXhMRow@mail.gmail.com>\n <CAMe9rOrtX3jcEAz6xNCtrCAC_LteYSN=WHUkiXGX1cG=-ROknA@mail.gmail.com>\n <685p4q03-1p87-81p4-08q5-12092or2729r@fhfr.qr>\n <7rqs2531-3r59-r8on-1520-soq92q4rn665@fhfr.qr>","In-Reply-To":"<7rqs2531-3r59-r8on-1520-soq92q4rn665@fhfr.qr>","From":"\"H.J. Lu\" <hjl.tools@gmail.com>","Date":"Mon, 13 Apr 2026 20:27:02 +0800","X-Gm-Features":"AQROBzCH93ZdRHm7-h3BFzVKb1NfQkUJsrPCnJBQjcEhz5NjDp_st-4NuqwPuIQ","Message-ID":"\n <CAMe9rOpbhxWrwXcsRiQC594-83oAQHw5ESdZsWT9R=_jcAz-NQ@mail.gmail.com>","Subject":"Re: [PATCH v6] x86: Rewrite ix86_find_max_used_stack_alignment","To":"Richard Biener <rguenther@suse.de>","Cc":"GCC Patches <gcc-patches@gcc.gnu.org>, Uros Bizjak <ubizjak@gmail.com>,\n Hongtao Liu <hongtao.liu@intel.com>, Sam James <sam@gentoo.org>,\n Richard Sandiford <rdsandiford@googlemail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]