[Bug middle-end/102997] New: 45% calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[Bug middle-end/102997] New: 45% calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

            Bug ID: 102997
           Summary: 45% calculix regression with LTO+PGO -march=native
                    -Ofast between
                    ce4d1f632ff3f680550d3b186b60176022f41190 and
                    6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is seen on zen3
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.170.0
zen2
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.170.0
zen1
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=8.170.0

Changes in range:
commit 6fca1761a16c68740f875fc487b98b6bde8e9be7
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 20 07:15:17 2021 +0200

    Remove unused back_threader destructor.

    Tested on x86-64 Linux.

    gcc/ChangeLog:

            * tree-ssa-threadbackward.c (back_threader::~back_threader):
Remove.

commit 8b7f9c40ef42411b6f51b508d41a580d4682069e
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue Oct 19 10:26:47 2021 +0200

    Remove superflous debugging messages from the threading registry.

    These are some random obvious cleanups to the threading dumps, since
    it seems I'm not the only one looking at dumps these days.

    The "just threaded" debugging message is redundant since there's
    already an equivalent "Registering jump thread" message.

    The "about to thread" message is actually confusing, because the source
    block doesn't match the IL, since the CFG update is mid-flight.

    Tested on x86-64 Linux.

    gcc/ChangeLog:

            * tree-ssa-threadupdate.c
(back_jt_path_registry::adjust_paths_after_duplication):
            Remove superflous debugging message.
            (back_jt_path_registry::duplicate_thread_path): Same.

commit 18606d776642a876a787c37491c52b81c30ebc83
Author: Bob Duff <duff@adacore.com>
Date:   Sat Oct 16 15:30:45 2021 -0400

    [Ada] Remove unnecessary call to No_Uint_To_0

    gcc/ada/

            * gcc-interface/decl.c (gnat_to_gnu_entity): Remove unnecessary
            call to No_Uint_To_0.

commit 4afb464e1f76d63d89c4034f78d5ebb3400eaf3c
Author: Richard Kenner <kenner@adacore.com>
Date:   Thu Oct 14 15:31:38 2021 -0400

    [Ada] Never treat intrinsic subprograms as nested

    gcc/ada/

            * exp_unst.adb (Visit_Node, when N_Subprogram_Call): Never treat
            instrinsic subprograms as nested.

commit bd2560b726fa93b61060a9f469ad288c512961f3
Author: Yannick Moy <moy@adacore.com>
Date:   Mon Aug 30 16:33:00 2021 +0200

    [Ada] Proof of the runtime support for attribute 'Width

    gcc/ada/

            * libgnat/s-widlllu.ads: Mark in SPARK.
            * libgnat/s-widllu.ads: Likewise.
            * libgnat/s-widuns.ads: Likewise.
            * libgnat/s-widthu.adb: Add ghost code and a
            pseudo-postcondition.

commit c5742a0e1191365c57bc06fdbf1ff5da1028f127
Author: Yannick Moy <moy@adacore.com>
Date:   Fri Oct 15 12:00:16 2021 +0200

    [Ada] Provide dummy body for big integers library used in reduced runtimes

    gcc/ada/

            * libgnat/a-nbnbin__ghost.adb (Signed_Conversions,
            Unsigned_Conversions): Mark subprograms as not imported.
            * libgnat/a-nbnbin__ghost.ads: Provide a dummy body.

commit 723d09e8895733f065200fa1b54c84243cf96f69
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Thu Oct 14 15:44:48 2021 +0200

    [Ada] Fix problematic conversion of real literal in static context

    gcc/ada/

            * sem_eval.adb (Eval_Type_Conversion): If the target subtype is
            a static floating-point subtype and the result is a real literal,
            consider its machine-rounded value to raise Constraint_Error.
            (Test_In_Range): Turn local variables into constants.

commit f6f8b3f95e55084b59ecc8fbe0f0cfd485d58c39
Author: Doug Rupp <rupp@adacore.com>
Date:   Thu Oct 14 08:41:56 2021 -0700

    [Ada] Delete unused runtime files

    gcc/ada/

            * libgnat/g-io-put__vxworks.adb: Remove (unused)
            * libgnat/s-parame__ae653.ads: Likewise.
            * libgnat/s-thread.ads: Likewise.
            * libgnat/s-thread__ae653.adb: Likewise.

commit 60440d3cf51acb9cb63543d5bb71fd50cfdd9470
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Oct 13 20:50:28 2021 +0200

    [Ada] Factor out machine rounding operations

    gcc/ada/

            * sem_eval.ads (Machine_Number): New inline function.
            * sem_eval.adb (Machine_Number): New function body implementing
            the machine rounding operation specified by RM 4.9(38/2).
            (Check_Non_Static_Context): Call Machine_Number and set the
            Is_Machine_Number flag consistently on the resulting node.
            * sem_attr.adb (Eval_Attribute) <Attribute_Machine>: Likewise.
            * checks.adb (Apply_Float_Conversion_Check): Call Machine_Number.
            (Round_Machine): Likewise.

commit 931d4819f740ade9707436447b6d7a1148d65d54
Author: Johannes Kliemann <kliemann@adacore.com>
Date:   Fri Oct 8 15:55:33 2021 +0000

    [Ada] Define __wrs_rtp_base in linker spec

    gcc/ada/

            * vxworks7-cert-rtp-link.spec: Add the definition of
            __wrs_rtp_base.

commit 6cf01c9277b81b81e8d09fe770b5fafe25fd880f
Author: Piotr Trojanek <trojanek@adacore.com>
Date:   Wed Oct 13 13:40:28 2021 +0200

    [Ada] Reject boxes in delta record aggregates

    gcc/ada/

            * sem_aggr.adb (Resolve_Delta_Record_Aggregate): Reject boxes in
            record delta aggregates.

commit 50cdd660b2ac54abb2659c7a88200d4c2fd1f195
Author: Justin Squirek <squirek@adacore.com>
Date:   Thu Sep 23 11:04:25 2021 -0400

    [Ada] Missing accessibility check when returning discriminated types

    gcc/ada/

            * sem_ch6.adb (Check_Return_Construct_Accessibility): Modify
            generation of accessibility checks to be more consolidated and
            get triggered properly in required cases.
            * sem_util.adb (Accessibility_Level): Add extra check within
            condition to handle aliased formals properly in more cases.

commit 9267014b351edf5aa0d0951545ec405edec5e3f5
Author: Justin Squirek <squirek@adacore.com>
Date:   Tue Oct 12 14:04:16 2021 -0400

    [Ada] Crash on object of protected type with defaulted access component

    gcc/ada/

            * exp_ch7.adb (Make_Final_Call): Detect expanded protected types
            and use original protected type in order to calculate
            appropriate finalization routine.

commit 0f074aa4aa248e9602765155acff57604c1d9778
Author: Johannes Kliemann <kliemann@adacore.com>
Date:   Thu Sep 30 13:41:13 2021 +0200

    [Ada] Add ghost code version of Ada.Numerics.Big_Numbers.Big_Integers

    gcc/ada/

            * libgnat/a-nbnbin__ghost.ads: Add ghost package.

commit 2aa814cb27fe3f61adfe894d52f01a4c377263fe
Author: Piotr Trojanek <trojanek@adacore.com>
Date:   Wed Oct 13 13:48:42 2021 +0200

    [Ada] Refine type of a counter function for record delta aggregate

    gcc/ada/

            * sem_aggr.adb (Variant_Depth): Refine type from Integer to
            Natural.

commit 36e38022125f2f336e5d281fb3e5e66191d21e73
Author: Bob Duff <duff@adacore.com>
Date:   Wed Oct 6 09:03:53 2021 -0400

    [Ada] tech debt: Clean up Uint fields, such as Esize

    gcc/ada/

            * atree.ads: Comment improvements. How is a "completely new
            node" different from a "new node"? Document default values
            corresponding to field types.
            * exp_ch7.adb (Process_Tagged_Type_Declaration): Use
            higher-level Scope_Depth instead of Scope_Depth_Value.  Remove
            confusing comment: not clear what a "true" library level package
            is.
            * uintp.adb (Image_Out): Print No_Uint in a more readable way.
            * gen_il-gen.adb, gen_il-gen-gen_entities.adb,
            gen_il-gen-gen_nodes.adb, gen_il-types.ads: Tighten up the
            subtypes of fields whose type is Uint, where possible; use
            more-constrained subtypes such as Unat.
            * einfo-utils.adb, einfo-utils.ads, exp_attr.adb,
            exp_ch3.adb, exp_intr.adb, exp_unst.adb, exp_util.adb,
            freeze.adb, repinfo.adb, sem.adb, sem_ch12.adb, sem_ch13.adb,
            sem_ch3.adb, sem_ch8.adb, sem_util.adb, sprint.adb, treepr.adb:
            No longer use Uint_0 to indicate "unknown" or "not yet known"
            for various fields whose type is Uint. Use No_Uint for that,
            except in a small number of legacy cases that cause test
            failures. Protect many queries of such fields with calls to
            Known_... functions. Improve comments.
            * exp_aggr.adb: Likewise.
            (Is_OK_Aggregate): Check whether Csiz is present.
            (Aggr_Assignment_OK_For_Backend): Ensure we do not access an
            uninitialized size.
            * exp_strm.adb (Build_Elementary_Input_Call,
            Build_Elementary_Write_Call): Check whether P_Size is present.
            * cstand.adb: Leave Component_Size of Any_Composite unknown.
            Similar for RM_Size of Standard_Exception_Type.  These should
            not be used.
            * einfo.ads: Comment improvements.
            * exp_disp.ads: Minor.
            * gen_il-internals.ads, gen_il-internals.adb: Minor.
            * sinfo-utils.adb: Take advantage of full-coverage rules.
            * types.h: Minor.

commit 749e01a5f310f2c4327f030d425aa6e23afbbbd5
Author: Gary Dismukes <dismukes@adacore.com>
Date:   Fri Oct 8 17:57:37 2021 -0400

    [Ada] Warning on nonmatching subtypes in fully conforming subprogram specs
and bodies

    gcc/ada/

            * sem_ch6.adb: Add with and use of Warnsw.
            (Check_Conformance): Report a warning when subtypes or
            designated subtypes of formal parameters or result subtypes
            denote different declarations between the spec and body of the
            (Subprogram_Subtypes_Have_Same_Declaration): New function nested
            within Check_Conformance that determines whether two subtype
            entities referenced in a subprogram come from the same
            declaration. Returns True immediately if the subprogram is in a
            generic instantiation, or the subprogram is marked Is_Internal
            or is declared in an internal (GNAT library) unit, or GNAT_Mode
            is enabled, otherwise compares the nonlimited views of the
            entities (or their designated subtypes' nonlimited views in the
            anonymous access cases).
            (Nonlimited_View_Of_Subtype): New function nested within
            function Subprogram_Subtypes_Have_Same_Declaration that returns
            Non_Limited_View of a type or subtype that is an incomplete or
            class-wide type that comes from a limited of a
            package (From_Limited_With is True for the entity), or returns
            Full_View when the nonlimited view is an incomplete type.
            Otherwise returns the entity passed in.
            * warnsw.ads (Warn_On_Pedantic_Checks): New warning flag.
            (type Warning_Record): New component Warn_On_Pedantic_Checks.
            * warnsw.adb (All_Warnings): Set Warn_On_Pedantic_Checks from
            parameter Setting.
            (Restore_Warnings): Restore the value of the
            Warn_On_Pedantic_Checks flag.
            (Save_Warnings): Save the value of the Warn_On_Pedantic_Checks
            flag.
            (Set_Underscore_Warning_Switch): Add settings of the
            Warn_On_Pedantic flag according to the switch ("-gnatw_p" vs.
            "-gnatw_P").
            * doc/gnat_ugn/building_executable_programs_with_gnat.rst: Add
            documentation of new switches -gnatw_p and -gnatw_P (warnings
            for pedantic checks).
            * gnat_ugn.texi: Regenerate.
            * usage.adb: Add Warn_On_Pedantic_Checks.

commit ff2746728050429684bf62729df798189cc1d396
Author: Piotr Trojanek <trojanek@adacore.com>
Date:   Tue Oct 12 17:42:05 2021 +0200

    [Ada] Prevent use of an uninitialized AST field with universal integer

    gcc/ada/

            * exp_spark.adb (Expand_SPARK_N_Attribute_Reference): Guard
            against equality of an uninitialized RM_Size field.

commit d24e5767fe780653d5601b69d981f33e2a62e47e
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Mon Oct 11 16:16:41 2021 +0200

    [Ada] Expose and use type-generic GCC atomic builtins

    gcc/ada/

            * sem_ch12.adb (Analyze_Subprogram_Instantiation): Also propagate
an
            interface name on an intrinsic subprogram.  Remove obsolete
comment.
            * libgnat/s-atopri.ads (Atomic_Load): New generic intrinsic
function
            (Atomic_Load_8): Rewrite into instantiation.
            (Atomic_Load_16): Likewise.
            (Atomic_Load_32): Likewise.
            (Atomic_Load_64): Likewise.
            (Sync_Compare_And_Swap): New generic intrinsic function.
            (Sync_Compare_And_Swap_8): Rewrite into instantiation.
            (Sync_Compare_And_Swap_16): Likewise.
            (Sync_Compare_And_Swap_32): Likewise.
            (Sync_Compare_And_Swap_64): Likewise.
            (Lock_Free_Read): New generic inline function.
            (Lock_Free_Read_8): Rewrite into instantiation.
            (Lock_Free_Read_16): Likewise.
            (Lock_Free_Read_32): Likewise.
            (Lock_Free_Read_64): Likewise.
            (Lock_Free_Try_Write): New generic inline function.
            (Lock_Free_Try_Write_8): Rewrite into instantiation.
            (Lock_Free_Try_Write_16): Likewise.
            (Lock_Free_Try_Write_32): Likewise.
            (Lock_Free_Try_Write_64): Likewise.
            * libgnat/s-atopri.adb (Lock_Free_Read): New function body.
            (Lock_Free_Read_8): Delete.
            (Lock_Free_Read_16): Likewise.
            (Lock_Free_Read_32): Likewise.
            (Lock_Free_Read_64): Likewise.
            (Lock_Free_Try_Write): New function body.
            (Lock_Free_Try_Write_8): Delete.
            (Lock_Free_Try_Write_16): Likewise.
            (Lock_Free_Try_Write_32): Likewise.
            (Lock_Free_Try_Write_64): Likewise.
            * libgnat/s-aoinar.adb (Atomic_Fetch_And_Add): Use type-generic GCC
            atomic builtin and tidy up implementation.
            (Atomic_Fetch_And_Subtract): Likewise.
            * libgnat/s-aomoar.adb (Atomic_Fetch_And_Add): Likewise.
            (Atomic_Fetch_And_Subtract): Likewise.
            * libgnat/s-atopex.adb (Atomic_Exchange): Likewise.
            (Atomic_Compare_And_Exchange): Likewise.

commit abb540a70b05556da1b318e67f82d668b93d0824
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Tue Oct 12 11:56:46 2021 +0200

    [Ada] Rewrite tests on Convention_Intrinsic

    gcc/ada/

            * gcc-interface/decl.c (gnat_to_gnu_entity) <E_Subprogram_Type>:
            Replace test on Convention_Intrinsic with Is_Intrinsic_Subprogram.
            (gnat_to_gnu_param): Likewise.
            (gnat_to_gnu_subprog_type): Likewise.
            * gcc-interface/trans.c (elaborate_all_entities_for_package):
Ditto.

commit 4b39bab947436640c20624ec58b61830c8ab2d71
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Mon Oct 11 16:56:06 2021 +0200

    [Ada] Small cleanup in Eval_Integer_Literal

    gcc/ada/

            * sem_eval.ads (Check_Non_Static_Context): Update documentation.
            * sem_eval.adb (In_Any_Integer_Context): Change parameter type,
            adjust accordingly and remove unreachable case.
            (Eval_Integer_Literal): Consider the node kind throughout and
            trim down verbose condition.

commit 0a8dcff179804d928b20ea8c2a40bc73035acaf3
Author: Doug Rupp <rupp@adacore.com>
Date:   Mon Sep 20 10:31:02 2021 -0700

    [Ada] Get rid of Frontend_Exceptions refs

    gcc/ada/

            * Makefile.rtl: Remove references to system-vxworks-ppc.ads
            and system-vxworks-x86.ads.
            * libgnat/system-vxworks-ppc.ads: Remove.
            * libgnat/system-vxworks-ppc-ravenscar.ads: Likewise.
            * libgnat/system-vxworks-x86.ads: Likewise.

commit 8c73de6ea4c05d11b278626e170d5932d7955095
Author: Yannick Moy <moy@adacore.com>
Date:   Thu Oct 7 09:05:45 2021 +0200

    [Ada] Issue warning on unused quantified expression

    gcc/ada/

            * sem_ch4.adb (Analyze_QUantified_Expression): Issue warning on
            conjunct/disjunct sub-expression of the full expression inside a
            quantified expression, when it does not reference the quantified
            variable.

commit d9fe0e53d8dbc7cae3170cd6ad783100ec3a704a
Author: Marc Poulhiès <poulhies@adacore.com>
Date:   Fri Oct 8 10:02:11 2021 +0200

    [Ada] Fix type conversion handling in validity checks

    gcc/ada/

            * checks.adb (Insert_Valid_Check): in case of checked type
            conversion, update Typ to match Exp's type and add call to
            Analyze_And_Resolve.

commit b47b5438b9b95cea90f8d925518e893259255a50
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 20 09:06:18 2021 +0200

    Remove unused back_threader_registry::m_threaded_paths.

    Tested on x86-64 Linux.

    gcc/ChangeLog:

            * tree-ssa-threadbackward.c
(back_threader_registry::back_threader_registry):
            Remove.
            (back_threader_registry::register_path): Remove m_threaded_paths.

commit 82cd78f2c31db1664ca154d7fcd24e9eaee1427f
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 20 09:05:23 2021 +0200

    Restore --param=max-fsm-thread-length

    The removal of --param=max-fsm-thread-length is causing code
    explosion.  I thought that --param=max-fsm-thread-path-insns was a
    better gague for path profitability than raw BB length, but it turns
    out that we don't take into account PHIs when estimating the number of
    statements.

    In this PR, we have a sequence of very large PHIs that have us
    traversing extremely large paths that blow up the compilation.

    We could fix this a couple of different ways.  We could avoid
    traversing more than a certain number of PHI arguments, or ignore
    large PHIs altogether.  The old implementation certainly had this
    knob, and we could cut things off before we even got to the ranger.
    We could also adjust the instruction estimation to take into account
    PHIs, but I'm sure we'll mess something else in the process ;-).

    The easiest thing to do is just restore the knob.

    At a later time we could tweak this further, for instance,
    disregarding empty blocks in the count.  BTW, this is the reason I
    didn't chop things off in the lowlevel registry for all threaders: the
    forward threader can't really explore too deep paths, but it could
    theoretically get there while threading over empty blocks.

    This fixes 102814, 102852, and I bet it solves the Linux kernel cross
    compile issue.

    Tested on x86-64 Linux.

    gcc/ChangeLog:

            PR tree-optimization/102814
            * doc/invoke.texi: Document --param=max-fsm-thread-length.
            * params.opt: Add --param=max-fsm-thread-length.
            * tree-ssa-threadbackward.c
            (back_threader_profitability::profitable_path_p): Fail on paths
            longer than max-fsm-thread-length.

commit 972ee845f54839e9bd2e4611bb268d75440f3845
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Oct 20 10:42:56 2021 +0200

    Fix PR middle-end/102764

    This is a regression present on the mainline in the form of -fcompare-debug
    failure at -O3 on a compiler-generated testcase.  Fixed by disregarding a
    debug statement in the last position of a basic block to reset the current
    location for the outgoing edges.

    gcc/
            PR middle-end/102764
            * cfgexpand.c (expand_gimple_basic_block): Disregard a final debug
            statement to reset the current location for the outgoing edges.

    gcc/testsuite/
            * gcc.dg/pr102764.c: New test.

commit 8fe93cc664ded8cc1952da28b23f3fc68504a73e
Author: Arnaud Charlet <charlet@adacore.com>
Date:   Wed Oct 20 10:23:40 2021 +0200

    Avoid exception propagation during bootstrap

    This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for
    32-bit Windows in the MSYS setup.  The PR shows that we cannot rely on
    exception propagation being operational during the bootstrap, at least on
    the 11 branch, so fix this by removing the problematic raise statement.

    gcc/ada/
            PR ada/100486
            * sem_prag.adb (Check_Valid_Library_Unit_Pragma): Do not raise an
            exception as part of the bootstrap.

commit c7abdf46fb7ac9a0c37f120feff3fcc3a752584f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Oct 20 09:34:51 2021 +0200

    openmp: Fix up struct gomp_work_share handling [PR102838]

    If GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is not defined, the intent was to
    treat the split of the structure between first cacheline (64 bytes)
    as mostly write-once, use afterwards and second cacheline as rw just
    as an optimization.  But as has been reported, with vectorization enabled
    at -O2 it can now result in aligned vector 16-byte or larger stores.
    When not having posix_memalign/aligned_alloc/memalign or other similar API,
    alloc.c emulates it but it needs to allocate extra memory for the dynamic
    realignment.
    So, for the GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC not defined case, this patch
    stops using aligned (64) attribute in the middle of the structure and
instead
    inserts padding that puts the second half of the structure at offset 64
bytes.

    And when GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is defined, usually it was
allocated
    as aligned, but for the orphaned case it could still be allocated just with
    gomp_malloc without guaranteed proper alignment.

    2021-10-20  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/102838
            * libgomp.h (struct gomp_work_share_1st_cacheline): New type.
            (struct gomp_work_share): Only use aligned(64) attribute if
            GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is defined, otherwise just
            add padding before lock to ensure lock is at offset 64 bytes
            into the structure.
            (gomp_workshare_struct_check1, gomp_workshare_struct_check2):
            New poor man's static assertions.
            * work.c (gomp_work_share_start): Use gomp_aligned_alloc instead of
            gomp_malloc if GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC.

commit d4044db034b40c275b5f287d5854a102d22e07c0
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Wed Oct 20 08:32:16 2021 +0200

    gfortran.dg/bind-c-contiguous-5.c: Big-endian fix

    gcc/testsuite/

            PR fortran/102815
            * gfortran.dg/bind-c-contiguous-5.c (do_call, reset_var): Handle
            big andian.

commit 424945258d1778617b5d3d5273f6e1c10e718f80
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Oct 20 08:38:58 2021 +0200

    c++: Fix up push_local_extern_decl_alias error recovery [PR102642]

    My recent push_local_extern_decl_alias change broke error-recovery,
    do_pushdecl can return error_mark_node and set_decl_tls_model can't be
    called on that.  There are other code paths that store error_mark_node
    into DECL_LOCAL_DECL_ALIAS, with the intent to differentiate the cases
    where we haven't yet tried to push it into the namespace scope (NULL)
    and one where we have tried it but it failed (error_mark_node), but looking
    around, there are other spots where we call functions or do processing
    which doesn't tolerate error_mark_node.

    So, the first hunk with the testcase fixes the testcase, the others
    fix what I've spotted and the fix was easy to figure out (there are I think
    3 other spots mainly for function multiversioning).

    2021-10-20  Jakub Jelinek  <jakub@redhat.com>

            PR c++/102642
            * name-lookup.c (push_local_extern_decl_alias): Don't call
            set_decl_tls_model on error_mark_node.
            * decl.c (make_rtl_for_nonlocal_decl): Don't call
            set_user_assembler_name on error_mark_node.
            * parser.c (cp_parser_oacc_declare): Ignore DECL_LOCAL_DECL_ALIAS
            if it is error_mark_node.
            (cp_parser_omp_declare_target): Likewise.

            * g++.dg/tls/pr102642.C: New test.

commit d8edfadfc7a9795b65177a50ce44fd348858e844
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon Oct 4 09:47:02 2021 +0200

    Disallow loop rotation and loop header crossing in jump threaders.

    There is a lot of fall-out from this patch, as there were many threading
    tests that assumed the restrictions introduced by this patch were valid.
    Some tests have merely shifted the threading to after loop
    optimizations, but others ended up with no threading opportunities at
    all.  Surprisingly some tests ended up with more total threads.  It was
    a crapshoot all around.

    On a postive note, there are 6 tests that no longer XFAIL, and one
    guality test which now passes.

    I felt a bit queasy about such a fundamental change wrt threading, so I
    ran it through my callgrind test harness (.ii files from a bootstrap).
    There was no change in overall compilation, DOM, or the VRP threaders.

    However, there was a slight increase of 1.63% in the backward threader.
    I'm pretty sure we could reduce this if we incorporated the restrictions
    into their profitability code.  This way we could stop the search when
    we ran into one of these restrictions.  Not sure it's worth it at this
    point.

    Tested on x86-64 Linux.

    Co-authored-by: Richard Biener <rguenther@suse.de>

    gcc/ChangeLog:

            * tree-ssa-threadupdate.c (cancel_thread): Dump threading reason
            on the same line as the threading cancellation.
            (jt_path_registry::cancel_invalid_paths): Avoid rotating loops.
            Avoid threading through loop headers where the path remains in the
            loop.

    libgomp/ChangeLog:

            * testsuite/libgomp.graphite/force-parallel-5.c: Remove xfail.

    gcc/testsuite/ChangeLog:

            * gcc.dg/Warray-bounds-87.c: Remove xfail.
            * gcc.dg/analyzer/pr94851-2.c: Remove xfail.
            * gcc.dg/graphite/pr69728.c: Remove xfail.
            * gcc.dg/graphite/scop-dsyr2k.c: Remove xfail.
            * gcc.dg/graphite/scop-dsyrk.c: Remove xfail.
            * gcc.dg/shrink-wrap-loop.c: Remove xfail.
            * gcc.dg/loop-8.c: Adjust for new threading restrictions.
            * gcc.dg/tree-ssa/ifc-20040816-1.c: Same.
            * gcc.dg/tree-ssa/pr21559.c: Same.
            * gcc.dg/tree-ssa/pr59597.c: Same.
            * gcc.dg/tree-ssa/pr71437.c: Same.
            * gcc.dg/tree-ssa/pr77445-2.c: Same.
            * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Same.
            * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same.
            * gcc.dg/vect/bb-slp-16.c: Same.
            * gcc.dg/tree-ssa/ssa-dom-thread-6.c: Remove.
            * gcc.dg/tree-ssa/ssa-dom-thread-18.c: Remove.
            * gcc.dg/tree-ssa/ssa-dom-thread-2a.c: Remove.
            * gcc.dg/tree-ssa/ssa-thread-invalid.c: New test.

commit f36240f8c835d792f788b6724e272fc0a4a4f26f
Author: Jeff Law <jeffreyalaw@gmail.com>
Date:   Wed Oct 20 00:26:59 2021 -0400

    Trivial fix to gil-1.c when analyzer is not enabled

    gcc/testsuite
            * gcc.dg/plugin/gil-1.c: Add dg-require-effective-target marker.

commit 9fbb6fa123be81c55e888e5d117e63d05780f0ed
Author: Siddhesh Poyarekar <siddhesh@gotplt.org>
Date:   Tue Oct 19 09:36:35 2021 +0530

    tree-object-size: Make unknown a computation

    Compute the unknown size value as a function of the min/max bit of
    object_size_type.  This transforms into a neat little branchless
    sequence on x86_64:

            movl    %edi, %eax
            sarl    %eax
            xorl    $1, %eax
            negl    %eax
            cltq

    which should be faster than loading the value from memory.  A quick
    unscientific test using

    `time make check-gcc RUNTESTFLAGS="dg.exp=builtin*"`

    shaves about half a second off execution time with this.  Also simplify
    implementation of unknown_object_size.

    gcc/ChangeLog:

            * tree-object-size.c (unknown): Make into a function.  Adjust
            all uses.
            (unknown_object_size): Simplify implementation.

    Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>

commit 3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt <hongtao.liu@intel.com>
Date:   Thu Oct 14 09:31:03 2021 +0800

    Adjust testcase for O2 vectorization.

    As discussed in [1], this patch add xfail/target selector to those
    testcases, also make a copy of them so that they can be tested w/o
    vectorization.

    Newly added xfail/target selectors are used to check the vectorization
    capability of continuous byte/double bytes storage, these scenarios
    are exactly the part of the testcases that regressed after O2
    vectorization.

    [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

    2021-10-19  Hongtao Liu  <hongtao.liu@intel.com>
                Kewen Lin  <linkw@linux.ibm.com>

    gcc/ChangeLog

            * doc/sourcebuild.texi (Effective-Target Keywords): Document
            vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
            vect_slp_v16qi_store, vect_slp_v2hi_store,
            vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

    gcc/testsuite/ChangeLog

            PR middle-end/102722
            PR middle-end/102697
            PR middle-end/102462
            PR middle-end/102706
            PR middle-end/102744
            * c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
            xfail/target selector.
            * gcc.dg/Warray-bounds-51.c: Ditto.
            * gcc.dg/Warray-parameter-3.c: Ditto.
            * gcc.dg/Wstringop-overflow-14.c: Ditto.
            * gcc.dg/Wstringop-overflow-21.c: Ditto.
            * gcc.dg/Wstringop-overflow-68.c: Ditto.
            * gcc.dg/Wstringop-overflow-76.c: Ditto.
            * gcc.dg/Warray-bounds-48.c: Ditto.
            * gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
            * lib/target-supports.exp (check_vect_slp_aligned_store_usage):
            New function.
            (check_effective_target_vect_slp_v2qi_store): Ditto.
            (check_effective_target_vect_slp_v4qi_store): Ditto.
            (check_effective_target_vect_slp_v8qi_store): Ditto.
            (check_effective_target_vect_slp_v16qi_store): Ditto.
            (check_effective_target_vect_slp_v2hi_store): Ditto.
            (check_effective_target_vect_slp_v4hi_store): Ditto.
            (check_effective_target_vect_slp_v2si_store): Ditto.
            (check_effective_target_vect_slp_v4si_store): Ditto.
            * c-c++-common/Wstringop-overflow-2-novec.c: New test.
            * gcc.dg/Warray-bounds-51-novec.c: New test.
            * gcc.dg/Warray-bounds-48-novec.c: New test.
            * gcc.dg/Warray-parameter-3-novec.c: New test.
            * gcc.dg/Wstringop-overflow-14-novec.c: New test.
            * gcc.dg/Wstringop-overflow-21-novec.c: New test.
            * gcc.dg/Wstringop-overflow-76-novec.c: New test.
            * gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

commit 19472fc3fc0cabcee5b8a5073e8128d21a1ed6f2
Author: GCC Administrator <gccadmin@gcc.gnu.org>
Date:   Wed Oct 20 00:16:43 2021 +0000

    Daily bump.

commit 5566f3c6b46cf053ae4b918513e318561b7af053
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 19 18:07:19 2021 -0400

    libstdc++: Implement LWG 3580 change to ranges::iota_view

    libstdc++-v3/ChangeLog:

            * include/std/ranges (iota_view::_Iterator::operator+): Adjust
            definition as per LWG 3580.
            (iota_view::_Iterator::operator-): Likewise.

commit bed1892f5b1a6601caa93d54c156a4d04d76ee7b
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 19 18:07:16 2021 -0400

    libstdc++: Implement LWG 3568 change to ranges::basic_istream_view

    libstdc++-v3/ChangeLog:

            * include/std/ranges (basic_istream_view::_M_object): Value
            initialize as per LWG 3568.

commit 98af6b86bc6cac705474c14bb3f9748f6866c859
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 19 18:07:05 2021 -0400

    libstdc++: Implement LWG 3470 change to ranges::subrange

    libstdc++-v3/ChangeLog:

            * include/bits/ranges_util.h
            (__detail::__uses_nonqualification_pointer_conversion): Define
            and use it ...
            (__detail::__convertible_to_nonslicing): ... here, as per LWG 3470.
            * testsuite/std/ranges/subrange/1.cc: New test.

commit 861440a77b62756d200ae356c4fdfd9653902e77
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 19 17:54:24 2021 -0400

    libstdc++: Implement LWG 3523 changes to ranges::iota_view

    libstdc++-v3/ChangeLog:

            * include/std/ranges (iota_view::_Iterator): Befriend iota_view.
            (iota_view::_Sentinel): Likewise.
            (iota_view::iota_view): Add three overloads, each taking an
            iterator/sentinel pair as per LWG 3523.
            * testsuite/std/ranges/iota/iota_view.cc (test06): New test.

commit 53b1c382d5a6fe8dec394a7ff820d77cda02af81
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 19 17:50:56 2021 -0400

    libstdc++: Implement LWG 3549 changes to ranges::enable_view

    This patch also reverts r11-3504 since that workaround is now obsolete
    after this resolution.

    libstdc++-v3/ChangeLog:

            * include/bits/ranges_base.h (view_interface): Forward declare.
            (__detail::__is_derived_from_view_interface_fn): Declare.
            (__detail::__is_derived_from_view_interface): Define as per LWG
3549.
            (enable_view): Adjust as per LWG 3549.
            * include/bits/ranges_util.h (view_interface): Don't derive from
            view_base.
            * include/std/ranges (filter_view): Revert r11-3504 change.
            (transform_view): Likewise.
            (take_view): Likewise.
            (take_while_view): Likewise.
            (drop_view): Likewise.
            (drop_while_view): Likewise.
            (join_view): Likewise.
            (lazy_split_view): Likewise.
            (split_view): Likewise.
            (reverse_view): Likewise.
            * testsuite/std/ranges/adaptors/sizeof.cc: Update expected sizes.
            * testsuite/std/ranges/view.cc (test_view::test_view): Remove
            this default ctor since views no longer need to be default
initable.
            (test01): New test.

commit c6a1fdd6dde3a95997731c8339d70970aca67594
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 20:37:53 2021 +0100

    doc: Fix typo in name of PowerPC __builtin_cpu_supports built-in

    gcc/ChangeLog:

            * doc/extend.texi (Basic PowerPC Built-in Functions): Fix typo.

commit 58f339fc5eaae7db9526f81ab91f282ad4a9b8cc
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 12:31:06 2021 +0100

    libstdc++: Implement std::random_device::entropy() for other sources

    Currently this function only returns a non-zero value for /dev/random
    and /dev/urandom. When a hardware instruction such as RDRAND is in use
    it should (in theory) be perfectly random and produce 32 bits of entropy
    in each 32-bit result. Add a helper function to identify the source of
    randomness from the _M_func and _M_file data members, and return a
    suitable value when RDRAND or RDSEED is being used.

    libstdc++-v3/ChangeLog:

            * src/c++11/random.cc (which_source): New helper function.
            (random_device::_M_getentropy()): Use which_source and return
            suitable values for sources other than device files.
            * testsuite/26_numerics/random/random_device/entropy.cc: New test.

commit 3cfbe5dc08b574bccc398256946cc03e2a767329
Author: Paul A. Clarke <pc@us.ibm.com>
Date:   Mon Aug 9 13:08:25 2021 -0500

    rs6000: Guard some x86 intrinsics implementations

    Some compatibility implementations of x86 intrinsics include
    Power intrinsics which require POWER8.  Guard them.

    emmintrin.h:
    - _mm_cmpord_pd: Remove code which was ostensibly for pre-POWER8,
      but which indeed depended on POWER8 (vec_cmpgt(v2du)/vcmpgtud).
      The "POWER8" version works fine on pre-POWER8.
    - _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
    pmmintrin.h:
    - _mm_movehdup_ps: vec_mergeo(v4su) uses vmrgow.
    - _mm_moveldup_ps: vec_mergee(v4su) uses vmrgew.
    smmintrin.h:
    - _mm_cmpeq_epi64: vec_cmpeq(v2di) uses vcmpequd.
    - _mm_mul_epi32: vec_mule(v4si) uses vmuluwm.
    - _mm_cmpgt_epi64: vec_cmpgt(v2di) uses vcmpgtsd.
    tmmintrin.h:
    - _mm_sign_epi8: vec_neg(v4si) uses vsububm.
    - _mm_sign_epi16: vec_neg(v4si) uses vsubuhm.
    - _mm_sign_epi32: vec_neg(v4si) uses vsubuwm.
      Note that the above three could actually be supported pre-POWER8,
      but current GCC does not support them before POWER8.
    - _mm_sign_pi8: depends on _mm_sign_epi8.
    - _mm_sign_pi16: depends on _mm_sign_epi16.
    - _mm_sign_pi32: depends on _mm_sign_epi32.

    sse4_2-pcmpgtq.c:
    - _mm_cmpgt_epi64: vec_cmpeq(v2di) uses vcmpequd.

    2021-10-19  Paul A. Clarke  <pc@us.ibm.com>

    gcc
            PR target/101893
            PR target/102719
            * config/rs6000/emmintrin.h: Guard POWER8 intrinsics.
            * config/rs6000/pmmintrin.h: Same.
            * config/rs6000/smmintrin.h: Same.
            * config/rs6000/tmmintrin.h: Same.

    gcc/testsuite
            * gcc.target/powerpc/sse4_2-pcmpgtq.c: Tighten dg constraints
            to minimally Power8.

commit ce8add4b0e086e671a7e08503408356ad6beee7f
Author: Paul A. Clarke <pc@us.ibm.com>
Date:   Mon Oct 18 19:12:12 2021 -0500

    rs6000: Add nmmintrin.h to extra_headers

    Fix an omission in commit 29fb1e831bf1c25e4574bf2f98a9f534e5c67665.

    2021-10-19  Paul A. Clarke  <pc@us.ibm.com>

    gcc
            * config.gcc (extra_headers): Add nmmintrin.h.

commit 04d392e8430ca66a3f12b7db4f3cb84788269a48
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 16:00:13 2021 +0100

    libstdc++: Fix doxygen generation to work with relative paths

    In r12-826 I tried to remove some redundant steps from the doxygen
    build, but they are needed when configure is run as a relative path. The
    use of pwd is to resolve the relative path to an absolute one.

    libstdc++-v3/ChangeLog:

            * doc/Makefile.am (stamp-html-doxygen, stamp-html-doxygen)
            (stamp-latex-doxygen, stamp-man-doxygen): Fix recipes for
            relative ${top_srcdir}.
            * doc/Makefile.in: Regenerate.

commit ff0eec94e87dfb7dc387f120ca5ade2707aecf50
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Oct 19 16:38:56 2021 +0200

    Fortran: Fix 'fn spec' for deferred character length

    Shows now up with gfortran.dg/deferred_type_param_6.f90 due to more ME
    optimizations, causing fails without this commit.

    gcc/fortran/ChangeLog:

            * trans-types.c (create_fn_spec): For allocatable/pointer
            character(len=:), use 'w' not 'R' as fn spec for the length dummy
            argument.

commit 7ef0cc444488e0bfa9b63d46307105e78ffc17a6
Author: Martin Liska <mliska@suse.cz>
Date:   Tue Oct 19 16:12:42 2021 +0200

    Make file utf8 valid input.

    liboffloadmic/ChangeLog:

            * include/coi/source/COIBuffer_source.h: Convert 2 chars to
            unicode.

commit 93bd0213885739a1073f8c98911f8a00c0eb5597
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Oct 18 15:55:22 2021 +0200

    Refactor vect_supportable_dr_alignment

    This refactors vect_supportable_dr_alignment to get the misalignment
    as input parameter which allows us to elide modifying/restoring
    of DR_MISALIGNMENT during alignment peeling analysis which eventually
    makes it more straight-forward to split out the negative step
    handling.

    2021-10-19  Richard Biener  <rguenther@suse.de>

            * tree-vectorizer.h (vect_supportable_dr_alignment): Add
            misalignment parameter.
            * tree-vect-data-refs.c (vect_get_peeling_costs_all_drs):
            Do not change DR_MISALIGNMENT in place, instead pass the
            adjusted misalignment to vect_supportable_dr_alignment.
            (vect_peeling_supportable): Likewise.
            (vect_peeling_hash_get_lowest_cost): Adjust.
            (vect_enhance_data_refs_alignment): Likewise.
            (vect_vfa_access_size): Likewise.
            (vect_supportable_dr_alignment): Add misalignment
            parameter and simplify.
            * tree-vect-stmts.c (get_negative_load_store_type): Adjust.
            (get_group_load_store_type): Likewise.
            (get_load_store_type): Likewise.

commit 5a8832b1659e311437d25b7ec8b078be27ae54b8
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 11:53:27 2021 +0100

    libstdc++: Change std::variant union member to empty struct

    This more clearly expresses the intent (a completely unused, trivial
    type) than using char. It's also consistent with the unions in
    std::optional.

    libstdc++-v3/ChangeLog:

            * include/std/variant (_Uninitialized): Use an empty struct
            for the unused union member, instead of char.

commit c4ecb11e4f7ea15f636e463248c8b14083bef05d
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 11:38:26 2021 +0100

    libstdc++: Fix std::stack deduction guide

    libstdc++-v3/ChangeLog:

            * include/bits/stl_stack.h (stack(Iterator, Iterator)): Remove
            non-deducible template parameter from deduction guide.
            * testsuite/23_containers/stack/deduction.cc: Check new C++23
            deduction guides.

commit 82b2e4f8cf5a01c6724fe3f465a77ee03cfcaae2
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 11:06:56 2021 +0100

    libstdc++: Implement monadic operations for std::optional (P0798R8)

    Another new addition to the C++23 working draft.

    The new member functions of std::optional are only defined for C++23,
    but the new members of _Optional_payload_base are defined for C++20 so
    that they can be used in non-propagating-cache in <ranges>. The
    _Optional_payload_base::_M_construct member can also be used in
    non-propagating-cache now, because it's constexpr since r12-4389.

    There will be an LWG issue about the feature test macro, suggesting that
    we should just bump the value of __cpp_lib_optional instead. I haven't
    done that here, but it can be changed once consensus is reached on the
    change.

    libstdc++-v3/ChangeLog:

            * include/std/optional (_Optional_payload_base::_Storage): Add
            constructor taking a callable function to invoke.
            (_Optional_payload_base::_M_apply): New function.
            (__cpp_lib_monadic_optional): Define for C++23.
            (optional::and_then, optional::transform, optional::or_else):
            Define for C++23.
            * include/std/ranges (__detail::__cached): Remove.
            (__detail::__non_propagating_cache): Remove use of __cached for
            contained value. Use _Optional_payload_base::_M_construct and
            _Optional_payload_base::_M_apply to set the contained value.
            * include/std/version (__cpp_lib_monadic_optional): Define.
            * testsuite/20_util/optional/monadic/and_then.cc: New test.
            * testsuite/20_util/optional/monadic/or_else.cc: New test.
            * testsuite/20_util/optional/monadic/or_else_neg.cc: New test.
            * testsuite/20_util/optional/monadic/transform.cc: New test.
            * testsuite/20_util/optional/monadic/version.cc: New test.

commit 6920d5a1a2834e9c62d441b8f4c6186b01107d13
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Oct 19 15:16:01 2021 +0200

    Fortran: Fix "str" to scalar descriptor conversion [PR92482]

            PR fortran/92482
    gcc/fortran/ChangeLog:

            * trans-expr.c (gfc_conv_procedure_call): Use TREE_OPERAND not
            build_fold_indirect_ref_loc to undo an ADDR_EXPR.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/bind-c-char-descr.f90: Remove xfail; extend a bit.

commit e3ef92e79f9f1c4275a9e19652439089a310627d
Author: Clément Chigot <clement.chigot@atos.net>
Date:   Thu Oct 14 09:03:13 2021 +0200

    aix: ensure reference to __tls_get_addr is in text section.

    The garbage collector of AIX linker might remove the reference to
    __tls_get_addr if it's added inside an unused csect, which can be
    the case of .data with very simple programs.

    gcc/ChangeLog:
    2021-10-19  Clément Chigot  <clement.chigot@atos.net>

            * config/rs6000/rs6000.c (rs6000_xcoff_file_end): Move
            __tls_get_addr reference to .text csect.

commit 6b34f5c5ec75823d656b6882f12d46248402a2aa
Author: Martin Liska <mliska@suse.cz>
Date:   Tue Oct 19 11:11:16 2021 +0200

    target: Support whitespaces in target attr/pragma.

            PR target/102375

    gcc/ChangeLog:

            * config/aarch64/aarch64.c (aarch64_process_one_target_attr):
            Strip whitespaces.

    gcc/testsuite/ChangeLog:

            * gcc.target/aarch64/pr102375.c: New test.

commit 5f5baf79927dfa8208f540cd1a441a56b0dfdb38
Author: Clément Chigot <clement.chigot@atos.net>
Date:   Tue Oct 19 13:20:14 2021 +0200

    MAINTAINERS: Add myself for write after approval

    ChangeLog:
    2021-10-19  Clément Chigot  <clement.chigot@atos.net>

            * MAINTAINERS: Add myself for write after approval.

commit 793d2549b173a0a2da6dd20ffc27acb9fd2de73e
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 19 12:40:59 2021 +0200

    Refactor load/store costing

    This passes down the already available alignment scheme and
    misalignment to the load/store costing routines, removing
    redundant queries.

    2021-10-19  Richard Biener  <rguenther@suse.de>

            * tree-vectorizer.h (vect_get_store_cost): Adjust signature.
            (vect_get_load_cost): Likewise.
            * tree-vect-data-refs.c (vect_get_data_access_cost): Get
            alignment support scheme and misalignment as arguments
            and pass them down.
            (vect_get_peeling_costs_all_drs): Compute that info here
            and note that we shouldn't need to.
            * tree-vect-stmts.c (vect_model_store_cost): Get
            alignment support scheme and misalignment as arguments.
            (vect_get_store_cost): Likewise.
            (vect_model_load_cost): Likewise.
            (vect_get_load_cost): Likewise.
            (vectorizable_store): Pass down alignment support scheme
            and misalignment to costing.
            (vectorizable_load): Likewise.

commit 9890b12c72c02828c691f22198c3e0afd8678991
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Oct 19 09:16:56 2021 +0100

    libstdc++: Fix mem-initializer in std::move_only_function [PR102825]

    libstdc++-v3/ChangeLog:

            PR libstdc++/102825
            * include/bits/mofunc_impl.h (move_only_function): Remove
            invalid base initializer.
            * testsuite/20_util/move_only_function/cons.cc: Instantiate
            constructors to check bodies.

commit 476ca5ade8522d566ffffeab0bece6a64aefeecd
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 19 11:36:13 2021 +0200

    Compute negative offset in get_load_store_type

    This moves the computation of a negative offset that needs to be
    applied when we vectorize a negative stride access to
    get_load_store_type alongside where we compute the actual access
    method.

    2021-10-19  Richard Biener  <rguenther@suse.de>

            * tree-vect-stmts.c (get_negative_load_store_type): Add
            offset output parameter and initialize it.
            (get_group_load_store_type): Likewise.
            (get_load_store_type): Likewise.
            (vectorizable_store): Use offset as computed by
            get_load_store_type.
            (vectorizable_load): Likewise.

commit d996799a507f9f4c379b55b004233be92fa63380
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 19 10:19:12 2021 +0200

    tree-optimization/102827 - avoid stmts in preheader

    The PR shows that when carefully crafting the runtime alias
    condition in the vectorizer we might end up using defs from
    the loop preheader but will end up inserting the condition
    before the .LOOP_VECTORIZED call.  So the following makes
    sure to insert invariants before that when we versioned the
    loop, preserving the invariant the vectorizer relies on.

    2021-10-19  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/102827
            * tree-if-conv.c (predicate_statements): Add pe parameter
            and use that edge to insert invariant stmts on.
            (combine_blocks): Pass through pe.
            (tree_if_conversion): Compute the edge to insert invariant
            stmts on and pass it along.

            * gcc.dg/pr102827.c: New testcase.

commit f98359ba9d3775319fb3181009be7d3dafe9ba15
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue Oct 19 11:00:10 2021 +0100

    PR target/102785: Correct addsub/subadd patterns on bfin.

    This patch resolves PR target/102785 where my recent patch to constant
    fold saturating addition/subtraction exposed a latent bug in the bfin
    backend.  The patterns used for blackfin's V2HI ssaddsub and sssubadd
    instructions had the indices/operations swapped.  This was harmless
    until we started evaluating these expressions at compile-time, when
    the mismatch was caught by the testsuite.

    2021-10-19  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/102785
            * config/bfin/bfin.md (addsubv2hi3, subaddv2hi3, ssaddsubv2hi3,
            sssubaddv2hi3):  Swap the order of operators in vec_concat.

commit 0910c516a3d72af048af27308349167f25c406c2
Author: Xionghu Luo <luoxhu@linux.ibm.com>
Date:   Tue Oct 19 04:02:04 2021 -0500

    rs6000: Remove unspecs for vec_mrghl[bhw]

    vmrghb only accepts permute index {0, 16, 1, 17, 2, 18, 3, 19, 4, 20,
    5, 21, 6, 22, 7, 23} no matter for BE or LE in ISA, similarly for vmrglb.
    Remove UNSPEC_VMRGH_DIRECT/UNSPEC_VMRGL_DIRECT pattern as vec_select
    + vec_concat as normal RTL.

    Tested pass on P8LE, P9LE and P8BE{m32}.

    gcc/ChangeLog:

    2021-10-19  Xionghu Luo  <luoxhu@linux.ibm.com>

            * config/rs6000/altivec.md (*altivec_vmrghb_internal): Delete.
            (altivec_vmrghb_direct): New.
            (*altivec_vmrghh_internal): Delete.
            (altivec_vmrghh_direct): New.
            (*altivec_vmrghw_internal): Delete.
            (altivec_vmrghw_direct_<mode>): New.
            (altivec_vmrghw_direct): Delete.
            (*altivec_vmrglb_internal): Delete.
            (altivec_vmrglb_direct): New.
            (*altivec_vmrglh_internal): Delete.
            (altivec_vmrglh_direct): New.
            (*altivec_vmrglw_internal): Delete.
            (altivec_vmrglw_direct_<mode>): New.
            (altivec_vmrglw_direct): Delete.
            * config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Adjust.
            * config/rs6000/rs6000.c (altivec_expand_vec_perm_const):
            Adjust.
            * config/rs6000/vsx.md (vsx_xxmrghw_<mode>): Adjust.
            (vsx_xxmrglw_<mode>): Adjust.

    gcc/testsuite/ChangeLog:

    2021-10-19  Xionghu Luo  <luoxhu@linux.ibm.com>

            * gcc.target/powerpc/builtins-1.c: Update instruction counts.

commit d2161caffbb56a434776608af4e4491b59e508c8
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue Oct 19 09:33:34 2021 +0200

    Change threading comment before pass_ccp pass.

    gcc/ChangeLog:

            * passes.def: Change threading comment before pass_ccp pass.

commit 91419baf4d0075d11e3667b816c83687288163fd
Author: Haochen Gui <guihaoc@gcc.gnu.org>
Date:   Tue Oct 19 16:28:31 2021 +0800

    Optimize the builtin vec_xl_sext

    gcc/
            * config/rs6000/rs6000-call.c (altivec_expand_lxvr_builtin):
            Modify the expansion for sign extension. All extensions are done
            within VSX registers.

    gcc/testsuite/
            * gcc.target/powerpc/p10_vec_xl_sext.c: New test.

commit 6b4c18b98127087d7f14062b81bc678f0589cd36
Author: prathamesh.kulkarni <prathamesh.kulkarni@linaro.org>
Date:   Tue Oct 19 13:51:51 2021 +0530

    [sve] PR93183 - Add support for conditional neg.

    gcc/testsuite/ChangeLog:
            PR target/93183
            * gcc.target/aarch64/sve/pr93183.c: Remove -mcpu=generic+sve from
dg-options.

commit d19d90289d1343e4fb0550eb1151db6da8a0d1ce
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Oct 18 14:59:54 2021 +0200

    Add misalignment output parameter to get_load_store_type

    This makes us compute the misalignment alongside the alignment support
    scheme in get_load_store_type, removing some out-of-place calls to
    the DR alignment API.

    2021-10-18  Richard Biener  <rguenther@suse.de>

            * tree-vect-stmts.c (get_group_load_store_type): Add
            misalignment output parameter and initialize it.
            (get_group_load_store_type): Likewise.
            (vectorizable_store): Remove now redundant queries.
            (vectorizable_load): Likewise.

commit f45610a45236e97616726ca042898d6ac46a082e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Oct 19 09:24:57 2021 +0200

    c++: Don't reject calls through PMF during constant evaluation [PR102786]

    The following testcase incorrectly rejects the c initializer,
    while in the s.*a case cxx_eval_* sees .__pfn reads etc.,
    in the s.*&S::foo case get_member_function_from_ptrfunc creates
    expressions which use INTEGER_CSTs with type of pointer to METHOD_TYPE.
    And cxx_eval_constant_expression rejects any INTEGER_CSTs with pointer
    type if they aren't 0.
    Either we'd need to make sure we defer such folding till cp_fold but the
    function and pfn_from_ptrmemfunc is used from lots of places, or
    the following patch just tries to reject only non-zero INTEGER_CSTs
    with pointer types if they don't point to METHOD_TYPE in the hope that
    all such INTEGER_CSTs with POINTER_TYPE to METHOD_TYPE are result of
    folding valid pointer-to-member function expressions.
    I don't immediately see how one could create such INTEGER_CSTs otherwise,
    cast of integers to PMF is rejected and would have the PMF RECORD_TYPE
    anyway, etc.

    2021-10-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/102786
            * constexpr.c (cxx_eval_constant_expression): Don't reject
            INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE.

            * g++.dg/cpp2a/constexpr-virtual19.C: New test.

commit caab0139761b04226fab14d87c4a4f981d942bbf
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Oct 18 15:55:22 2021 +0200

    Remove check_aligned parameter from vect_supportable_dr_alignment

    There are two calls with true as parameter, one is only relevant
    for the case of the misalignment being unknown which means the
    access is never aligned there, the other is in the peeling hash
    insert code used conditional on the unlimited cost model which
    adds an artificial count.  But the way it works right now is
    that it boosts the count if the specific misalignment when not peeling
    is unsupported - in particular when the access is currently aligned
    we'll query the backend with a misalign value of zero.  I've
    changed it to boost the peeling when unknown alignment is not
    supported instead and noted how we could in principle improve this.

    2021-10-19  Richard Biener  <rguenther@suse.de>

            * tree-vectorizer.h (vect_supportable_dr_alignment): Remove
            check_aligned argument.
            * tree-vect-data-refs.c (vect_supportable_dr_alignment):
            Likewise.
            (vect_peeling_hash_insert): Add supportable_if_not_aligned
            argument and do not call vect_supportable_dr_alignment here.
            (vect_peeling_supportable): Adjust.
            (vect_enhance_data_refs_alignment): Compute whether the
            access is supported with different alignment here and
            pass that down to vect_peeling_hash_insert.
            (vect_vfa_access_size): Adjust.
            * tree-vect-stmts.c (vect_get_store_cost): Likewise.
            (vect_get_load_cost): Likewise.
            (get_negative_load_store_type): Likewise.
            (get_group_load_store_type): Likewise.
            (get_load_store_type): Likewise.

commit df592811f950301ed3b10a08e476dad0f2eff26a
Author: Martin Liska <mliska@suse.cz>
Date:   Mon Oct 4 14:06:14 2021 +0200

    target: support spaces in target attribute.

            PR target/102374

    gcc/ChangeLog:

            * config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
Strip whitespaces.
            * system.h (strip_whilespaces): New function.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr102374.c: New test.

commit 38f6ee6bfc4633175ca6f6d29e597d379ccae820
Author: dianhong xu <dianhong.xu@intel.com>
Date:   Sat Oct 9 18:23:35 2021 +0800

    AVX512FP16: Add *_set1_pch intrinsics.

    Add *_set1_pch (_Float16 _Complex A) intrinsics.

    gcc/ChangeLog:

            * config/i386/avx512fp16intrin.h:
            (_mm512_set1_pch): New intrinsic.
            * config/i386/avx512fp16vlintrin.h:
            (_mm256_set1_pch): New intrinsic.
            (_mm_set1_pch): Ditto.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/avx512fp16-set1-pch-1a.c: New test.
            * gcc.target/i386/avx512fp16-set1-pch-1b.c: New test.
            * gcc.target/i386/avx512fp16vl-set1-pch-1a.c: New test.
            * gcc.target/i386/avx512fp16vl-set1-pch-1b.c: New test.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
                 CC|                            |rguenth at gcc dot gnu.org
             Target|                            |x86_64-*-*
           Keywords|                            |missed-optimization,
                   |                            |needs-bisection
            Summary|45% calculix regression     |[12 Regression] 45%
                   |with LTO+PGO -march=native  |454.calculix regression
                   |-Ofast between              |with LTO+PGO -march=native
                   |ce4d1f632ff3f680550d3b186b6 |-Ofast between
                   |0176022f41190 and           |ce4d1f632ff3f680550d3b186b6
                   |6fca1761a16c68740f875fc487b |0176022f41190 and
                   |98b6bde8e9be7 on Zen        |6fca1761a16c68740f875fc487b
                   |                            |98b6bde8e9be7 on Zen

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not seen on Haswell (but w/o PGO).  Is this PGO specific?  There's another
large jump visible end of 2019.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, IIRC calculix train data and ref data do not match up wrt the hottest
loops, so not sure whether any regression here is considered important.  Maybe
the profile is now preserved better.

I can't reproduce any slowdown w/o PGO.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
train data:

Samples: 6K of event 'cycles', Event count (approx.): 7715838425                
Overhead       Samples  Command          Shared Object                 Symbol   
   5.68%           382  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
insert.isra.0
   3.89%           262  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
isortii_
   2.36%           161  specperl         specperl                      [.]
Perl_hv_common
   1.94%           132  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
add_sm_st_
   1.69%           115  specperl         specperl                      [.]
S_regtry

ref data:

Samples: 601K of event 'cycles', Event count (approx.): 678304336437            
Overhead       Samples  Command          Shared Object                 Symbol   
  45.51%        274231  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
e_c3d_.constprop.0
  16.59%        100331  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
DVdot33
   7.91%         47070  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
GPart_smoothYSep
   3.54%         21391  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
Chv_updateS
   3.22%         19378  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
add_sm_st_
   2.71%         16238  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
SubMtx_sortColumnsUp
   2.43%         14549  calculix_peak.a  calculix_peak.amd64-m64-mine  [.]
IVqsortUp

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
> Not seen on Haswell (but w/o PGO).  Is this PGO specific?  There's another
> large jump visible end of 2019.
This is kabylake LTO+PGO+march=native 
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=5.170.0
seems there are no regressions.

Does not seem to reproduce on zens with -flto -Ofast -march=native
neighter with PGO but non-lto.

It is indeed possible that we misbehave based on profile, but I do not
see anything related to that in the revision range.

Honza

Re: [Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[Jan Hubicka]

> Not seen on Haswell (but w/o PGO).  Is this PGO specific?  There's another
> large jump visible end of 2019.
It is between 2019-11-15 and 18 but the revisions does not exist at git
- perhaps they reffer to the old git mirror. Martin will know better.

In that range there are many of Richard's vectorizer changes and my
patch fixing calculation of ref time in inliner which may be culprints.

Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> Not seen on Haswell (but w/o PGO).  Is this PGO specific?  There's another
> large jump visible end of 2019.
It is between 2019-11-15 and 18 but the revisions does not exist at git
- perhaps they reffer to the old git mirror. Martin will know better.

In that range there are many of Richard's vectorizer changes and my
patch fixing calculation of ref time in inliner which may be culprints.

Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
@Honza: Please do not paste all the revision changes in the bugzilla comment.
One  can easily investigate that from git revision range.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87166

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Btw, IIRC calculix train data and ref data do not match up wrt the hottest
> loops, so not sure whether any regression here is considered important. 
> Maybe the profile is now preserved better.
> 
> I can't reproduce any slowdown w/o PGO.

Yes, it's PR87166.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-01
     Ever confirmed|0                           |1
            Summary|[12 Regression] 45%         |[12 Regression] 45%
                   |454.calculix regression     |454.calculix regression
                   |with LTO+PGO -march=native  |with LTO+PGO -march=native
                   |-Ofast between              |-Ofast on Zen since
                   |ce4d1f632ff3f680550d3b186b6 |r12-4526-gd8edfadfc7a9795b6
                   |0176022f41190 and           |5177a50ce44fd348858e844
                   |6fca1761a16c68740f875fc487b |
                   |98b6bde8e9be7 on Zen        |
             Status|UNCONFIRMED                 |NEW
           Keywords|needs-bisection             |
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with Aldy's commit r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #8)
> Started with Aldy's commit
> r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.

Hmmm, this commit disables problematic threads we've agreed are detrimental to
loop form.  So it's not something the threader did, but something it's not
allowed to do.  This PR may need a loop expert to analyze.

I guess, technically it could be something we could catch past the loop
optimizers, but that's usually rarer.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #10 from hubicka at kam dot mff.cuni.cz ---
> 
> Hmmm, this commit disables problematic threads we've agreed are detrimental to
> loop form.  So it's not something the threader did, but something it's not
> allowed to do.  This PR may need a loop expert to analyze.
> 
> I guess, technically it could be something we could catch past the loop
> optimizers, but that's usually rarer.

In the patch you introduce crossed_loop_header variable which is only
set to true when loop header is visited but it does not seem to be
cleared when the loop is leaved.

I would expect that one wants to keep track of outermost loop entered
and check if the path left it later.

Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
>From what I gather, this is only reproducible with PGO.  If so, it may be worth
nothing that Jeff has mentioned that the backward threader probably does not do
a very good job with keeping profile counts up to date:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576437.html

The compute_path_counts function he mentions above is not even used by the
generic copier used by the backward threader, and currently all the threaders
with the exception of DOM are using the backward threader.

That being said, the commit this PR bisects to is not adding more threads, but
invalidating some.  Note the invalidation code works for all threaders, not
just the back threader.

This may have nothing to do with the issue at hand, but I thought it worth
mentioning.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
It's been mentioned that this SPEC test has irreconcilable differences between
the train and peak runs, and cannot be reasonably compared.  Is the slowdown
reported between two runs of compatible runs (two of the train data or two of
the peak data)?

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Since DOM is the only threading pass that keeps more or less accurate
profiling data, here's a very wild guess.

The pre-loop DOM threading pass does not thread some paths because of
the restrictions in place, which causes one of the post-loop backward
threaders (thread2 or threadfull2) to pick them up.  These will likely
not produce accurate profile info.

And I would also guess that the reason DOM3 (post loop) did not pick up the
threads was because the IL was sufficiently complicated for the simple path
discovery bits in the forward threader to catch.

This is all highly speculative, but that's the only scenario I can imagine
where this commit caused a profiling regression.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
I tend to close this issue due to a mismatch between train and reference run.
It's basically measuring speed of the cold code.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> 
> --- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Since DOM is the only threading pass that keeps more or less accurate
> profiling data, here's a very wild guess.
> 
> The pre-loop DOM threading pass does not thread some paths because of
> the restrictions in place, which causes one of the post-loop backward
> threaders (thread2 or threadfull2) to pick them up.  These will likely
> not produce accurate profile info.
> 
> And I would also guess that the reason DOM3 (post loop) did not pick up the
> threads was because the IL was sufficiently complicated for the simple path
> discovery bits in the forward threader to catch.
> 
> This is all highly speculative, but that's the only scenario I can imagine
> where this commit caused a profiling regression.

I think the important take-away is that we need to fix the profile
updating code (which is non-existant!) for the backwards threader
by looking at what the forward threader does, otherwise at least
profile-guided optimizations will be quite broken.

Re: [Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[Jan Hubicka]

Note that it still seems to me that the crossed_loop_header handling is
overly conservative.  We have:

@ -2771,6 +2771,7 @@ jt_path_registry::cancel_invalid_paths (vec<jump_thread_edge *> &path)
   bool seen_latch = false;
   int loops_crossed = 0;
   bool crossed_latch = false;
+  bool crossed_loop_header = false;
   // Use ->dest here instead of ->src to ignore the first block.  The
   // first block is allowed to be in a different loop, since it'll be
   // redirected.  See similar comment in profitable_path_p: "we don't
@@ -2804,6 +2805,14 @@ jt_path_registry::cancel_invalid_paths (vec<jump_thread_edge *> &path)
          ++loops_crossed;
        }
 
+      // ?? Avoid threading through loop headers that remain in the
+      // loop, as such threadings tend to create sub-loops which
+      // _might_ be OK ??.
+      if (e->dest->loop_father->header == e->dest
+         && !flow_loop_nested_p (exit->dest->loop_father,
+                                 e->dest->loop_father))
+       crossed_loop_header = true;
+
       if (flag_checking && !m_backedge_threads)
        gcc_assert ((path[i]->e->flags & EDGE_DFS_BACK) == 0);
     }
@@ -2829,6 +2838,21 @@ jt_path_registry::cancel_invalid_paths (vec<jump_thread_edge *> &path)
       cancel_thread (&path, "Path crosses loops");
       return true;
     }
+  // The path should either start and end in the same loop or exit the
+  // loop it starts in but never enter a loop.  This also catches
+  // creating irreducible loops, not only rotation.
+  if (entry->src->loop_father != exit->dest->loop_father
+      && !flow_loop_nested_p (exit->src->loop_father,
+                             entry->dest->loop_father))
+    {
+      cancel_thread (&path, "Path rotates loop");
+      return true;
+    }
+  if (crossed_loop_header)
+    {
+      cancel_thread (&path, "Path crosses loop header but does not exit it");
+      return true;
+    }
   return false;
 }
 
If I read it correctly, for a path that enters the loop and later leaves
it (where threading is desirable since we skip the whole loop) the logic
above will still return true (after finishing the whole walk which seems
like a waste).

This may trigger more often at -Os since we limit loop header copying.

And indeed, fixing profile updating would be nice.  Why the updating
code is not reused across different threaders?  (I wrote several thread
updating functions for varioius threaders introduced & remoed in the
past and I wonder why we need to keep reinventing it)

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #16 from hubicka at kam dot mff.cuni.cz ---
Note that it still seems to me that the crossed_loop_header handling is
overly conservative.  We have:

@ -2771,6 +2771,7 @@ jt_path_registry::cancel_invalid_paths
(vec<jump_thread_edge *> &path)
   bool seen_latch = false;
   int loops_crossed = 0;
   bool crossed_latch = false;
+  bool crossed_loop_header = false;
   // Use ->dest here instead of ->src to ignore the first block.  The
   // first block is allowed to be in a different loop, since it'll be
   // redirected.  See similar comment in profitable_path_p: "we don't
@@ -2804,6 +2805,14 @@ jt_path_registry::cancel_invalid_paths
(vec<jump_thread_edge *> &path)
          ++loops_crossed;
        }

+      // ?? Avoid threading through loop headers that remain in the
+      // loop, as such threadings tend to create sub-loops which
+      // _might_ be OK ??.
+      if (e->dest->loop_father->header == e->dest
+         && !flow_loop_nested_p (exit->dest->loop_father,
+                                 e->dest->loop_father))
+       crossed_loop_header = true;
+
       if (flag_checking && !m_backedge_threads)
        gcc_assert ((path[i]->e->flags & EDGE_DFS_BACK) == 0);
     }
@@ -2829,6 +2838,21 @@ jt_path_registry::cancel_invalid_paths
(vec<jump_thread_edge *> &path)
       cancel_thread (&path, "Path crosses loops");
       return true;
     }
+  // The path should either start and end in the same loop or exit the
+  // loop it starts in but never enter a loop.  This also catches
+  // creating irreducible loops, not only rotation.
+  if (entry->src->loop_father != exit->dest->loop_father
+      && !flow_loop_nested_p (exit->src->loop_father,
+                             entry->dest->loop_father))
+    {
+      cancel_thread (&path, "Path rotates loop");
+      return true;
+    }
+  if (crossed_loop_header)
+    {
+      cancel_thread (&path, "Path crosses loop header but does not exit it");
+      return true;
+    }
   return false;
 }

If I read it correctly, for a path that enters the loop and later leaves
it (where threading is desirable since we skip the whole loop) the logic
above will still return true (after finishing the whole walk which seems
like a waste).

This may trigger more often at -Os since we limit loop header copying.

And indeed, fixing profile updating would be nice.  Why the updating
code is not reused across different threaders?  (I wrote several thread
updating functions for varioius threaders introduced & remoed in the
past and I wonder why we need to keep reinventing it)

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeffreyalaw at gmail dot com

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #15)
> On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> > 
> > --- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> > Since DOM is the only threading pass that keeps more or less accurate
> > profiling data, here's a very wild guess.
> > 
> > The pre-loop DOM threading pass does not thread some paths because of
> > the restrictions in place, which causes one of the post-loop backward
> > threaders (thread2 or threadfull2) to pick them up.  These will likely
> > not produce accurate profile info.
> > 
> > And I would also guess that the reason DOM3 (post loop) did not pick up the
> > threads was because the IL was sufficiently complicated for the simple path
> > discovery bits in the forward threader to catch.
> > 
> > This is all highly speculative, but that's the only scenario I can imagine
> > where this commit caused a profiling regression.
> 
> I think the important take-away is that we need to fix the profile
> updating code (which is non-existant!) for the backwards threader
> by looking at what the forward threader does, otherwise at least
> profile-guided optimizations will be quite broken.

I totally agree.  Perhaps we could close this PR as WONTFIX since the test is
itself is deceiving, and open a new PR with the actual issue.

FWIW, in Jeff's original opinion:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576437.html

...I mention that gcc.dg/shrink-wrap-loop.c shows a regression due to profiling
differences.  Perhaps we could open a PR for that instead.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---

> If I read it correctly, for a path that enters the loop and later leaves
> it (where threading is desirable since we skip the whole loop) the logic
> above will still return true (after finishing the whole walk which seems
> like a waste).

Perhaps Richi can comment here, since this is his code?

> 
> This may trigger more often at -Os since we limit loop header copying.

Interesting.  We have PR102906 which is a code size increase at -Os on ARM for
the same commit.  I wonder if it's related.

> 
> And indeed, fixing profile updating would be nice.  Why the updating
> code is not reused across different threaders?  (I wrote several thread
> updating functions for varioius threaders introduced & remoed in the
> past and I wonder why we need to keep reinventing it)

This all predates me.  I don't know.  For the record, both threaders use
completely different BB copiers and update mechanisms.  It could be they're
sufficiently different that reusing it is unfeasible ??.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #19 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> 
> --- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> 
> > If I read it correctly, for a path that enters the loop and later leaves
> > it (where threading is desirable since we skip the whole loop) the logic
> > above will still return true (after finishing the whole walk which seems
> > like a waste).
> 
> Perhaps Richi can comment here, since this is his code?

The testcase would be

void test ()
{
        int i;
        if (test())
          i=0;
        else
          i=100;
        for (;i<100 && bar ();i++)
                do_work ();
}

Here I think we can thread else path to return w/o any issues with loop
nests even with -Os.

> 
> > 
> > This may trigger more often at -Os since we limit loop header copying.
> 
> Interesting.  We have PR102906 which is a code size increase at -Os on ARM for
> the same commit.  I wonder if it's related.
> 
> > 
> > And indeed, fixing profile updating would be nice.  Why the updating
> > code is not reused across different threaders?  (I wrote several thread
> > updating functions for varioius threaders introduced & remoed in the
> > past and I wonder why we need to keep reinventing it)
> 
> This all predates me.  I don't know.  For the record, both threaders use
> completely different BB copiers and update mechanisms.  It could be they're
> sufficiently different that reusing it is unfeasible ??.

Updating after trheading is not too hard however there is a painful
point that profile may disagree with fact you proved. In general you do
 1) you compute count of path your are threading (i.e. all edges you
 redirect to destination)
 2) all BBs along the path needs to have this count subtracted since
 they are not going to be executed on it anymore
 3) all conditionas on the path needs probabilities updated: you know
 the count entering the conditional and with same count you exit it via
 a particular edge.
 However here one needs to take into account that especially for guessed
 profiles (but for feedback too if code was duplicated earlier) the
 branch probability may be in a way that the leaving edge count is less
 than the count you want to subtract.

Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to hubicka from comment #19)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> > 
> > --- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> > 
> > > If I read it correctly, for a path that enters the loop and later leaves
> > > it (where threading is desirable since we skip the whole loop) the logic
> > > above will still return true (after finishing the whole walk which seems
> > > like a waste).
> > 
> > Perhaps Richi can comment here, since this is his code?
> 
> The testcase would be
> 
> void test ()
> {
>         int i;
>         if (test())
>           i=0;
>         else
>           i=100;
>         for (;i<100 && bar ();i++)
>                 do_work ();
> }
> 
> Here I think we can thread else path to return w/o any issues with loop
> nests even with -Os.

we fail this because

  // If we crossed a loop into an outer loop without crossing the
  // latch, this is just an early exit from the loop.
  if (loops_crossed == 1
      && !crossed_latch
      && flow_loop_nested_p (exit->dest->loop_father, exit->src->loop_father))
    return false;

does not trigger (loops_crossed == 2), and we then run into


  if (loops_crossed)
    {
      cancel_thread (&path, "Path crosses loops");
      return true;
    }

but the loops_crossed stuff is old and not from me, not sure what that's
useful for.  We could "fix" the accounting with

diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 8aac733ac25..52ec22e85e1 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2810,7 +2810,7 @@ jt_path_registry::cancel_invalid_paths
(vec<jump_thread_edge *> &path)

   // If we crossed a loop into an outer loop without crossing the
   // latch, this is just an early exit from the loop.
-  if (loops_crossed == 1
+  if (loops_crossed <= 2
       && !crossed_latch
       && flow_loop_nested_p (exit->dest->loop_father, exit->src->loop_father))
     return false;

to also allow to thread through a loop path not crossing the latch but
at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
be necessary.  It might still prevent us from doing such transforms when
it involves peeling.

> > 
> > > 
> > > This may trigger more often at -Os since we limit loop header copying.
> > 
> > Interesting.  We have PR102906 which is a code size increase at -Os on ARM for
> > the same commit.  I wonder if it's related.
> > 
> > > 
> > > And indeed, fixing profile updating would be nice.  Why the updating
> > > code is not reused across different threaders?  (I wrote several thread
> > > updating functions for varioius threaders introduced & remoed in the
> > > past and I wonder why we need to keep reinventing it)
> > 
> > This all predates me.  I don't know.  For the record, both threaders use
> > completely different BB copiers and update mechanisms.  It could be they're
> > sufficiently different that reusing it is unfeasible ??.
> 
> Updating after trheading is not too hard however there is a painful
> point that profile may disagree with fact you proved. In general you do
>  1) you compute count of path your are threading (i.e. all edges you
>  redirect to destination)
>  2) all BBs along the path needs to have this count subtracted since
>  they are not going to be executed on it anymore
>  3) all conditionas on the path needs probabilities updated: you know
>  the count entering the conditional and with same count you exit it via
>  a particular edge.
>  However here one needs to take into account that especially for guessed
>  profiles (but for feedback too if code was duplicated earlier) the
>  branch probability may be in a way that the leaving edge count is less
>  than the count you want to subtract.
> 
> Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #21 from hubicka at kam dot mff.cuni.cz ---
> to also allow to thread through a loop path not crossing the latch but
> at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
> be necessary.  It might still prevent us from doing such transforms when
> it involves peeling.

I am not sure what is the set of tranforms we want to forbid in general.
I think main situation we want to prevent is turning single-entry loop
to irreducible loop by forwarding loop entry edges differently.

For that it should be safe to trhead if the path enters a loop and later
leaves. For that we need to keep track of loops we entered in stack and
pop them when we leave it and check that stack is empty at the end.  (or
do stackless bookeeping but it may happen that we start in one loop,
leave it and then enter different loop and stop in it which is stil
unsafe so just comparing loop nest of entry and exit block is not right
thing to do)

It seems to me that it should be also OK to thread if we thread all
entry edges to the loop (in particular if it is only one) which should
be easy to check by looking into other edges entering the path being
threaded and checking that they are from loop and not from outside
(since the outside edges will keep the old path alive and we end up with
duplicated entry point).

I may miss something obvious, but I would say that all other threads
involving loops should be fine and better informed than peeling since
threader knows that the path in question is special.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> 
> --- Comment #21 from hubicka at kam dot mff.cuni.cz ---
> > to also allow to thread through a loop path not crossing the latch but
> > at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
> > be necessary.  It might still prevent us from doing such transforms when
> > it involves peeling.
> 
> I am not sure what is the set of tranforms we want to forbid in general.
> I think main situation we want to prevent is turning single-entry loop
> to irreducible loop by forwarding loop entry edges differently.
> 
> For that it should be safe to trhead if the path enters a loop and later
> leaves. For that we need to keep track of loops we entered in stack and
> pop them when we leave it and check that stack is empty at the end.  (or
> do stackless bookeeping but it may happen that we start in one loop,
> leave it and then enter different loop and stop in it which is stil
> unsafe so just comparing loop nest of entry and exit block is not right
> thing to do)

We verify that by simply looking at the loop depth relation of
the entry and exit of the path.

> It seems to me that it should be also OK to thread if we thread all
> entry edges to the loop (in particular if it is only one) which should
> be easy to check by looking into other edges entering the path being
> threaded and checking that they are from loop and not from outside
> (since the outside edges will keep the old path alive and we end up with
> duplicated entry point).
> 
> I may miss something obvious, but I would say that all other threads
> involving loops should be fine and better informed than peeling since
> threader knows that the path in question is special.

The issue is that the threader does not update loop info and it's
important to keep things like ->simdlen associated to the correct
loop and without distorting the loop in a way that invalidates such
info (pre loop optimization).  The forward threader contained some
code to keep loops up-to-date but as usual the backwards threader
is just broken with respect to this.

So yes, any threading that enters and leaves a loop is OK, but
a threading that rotates or peels a loop [not completely] is not
trivially so.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> We verify that by simply looking at the loop depth relation of
> the entry and exit of the path.

Which seem wrong for the path leaving loop and entering another...
> 
> > It seems to me that it should be also OK to thread if we thread all
> > entry edges to the loop (in particular if it is only one) which should
> > be easy to check by looking into other edges entering the path being
> > threaded and checking that they are from loop and not from outside
> > (since the outside edges will keep the old path alive and we end up with
> > duplicated entry point).
> > 
> > I may miss something obvious, but I would say that all other threads
> > involving loops should be fine and better informed than peeling since
> > threader knows that the path in question is special.
> 
> The issue is that the threader does not update loop info and it's
> important to keep things like ->simdlen associated to the correct
> loop and without distorting the loop in a way that invalidates such
> info (pre loop optimization).  The forward threader contained some
> code to keep loops up-to-date but as usual the backwards threader
> is just broken with respect to this.
> 
> So yes, any threading that enters and leaves a loop is OK, but
> a threading that rotates or peels a loop [not completely] is not
> trivially so.

I see. Did not think of that.
Perhaps something to solve incrementally next stage1

Honza

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> 
> --- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> > We verify that by simply looking at the loop depth relation of
> > the entry and exit of the path.
> 
> Which seem wrong for the path leaving loop and entering another...

True I guess.  The path should end it the same loop as it starts
or end in a loop containing the start loop.  Would have to double
check this.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #24)
> On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> > 
> > --- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> > > We verify that by simply looking at the loop depth relation of
> > > the entry and exit of the path.
> > 
> > Which seem wrong for the path leaving loop and entering another...
> 
> True I guess.  The path should end it the same loop as it starts
> or end in a loop containing the start loop.  Would have to double
> check this.

Yep, done:

  // The path should either start and end in the same loop or exit the
  // loop it starts in but never enter a loop.  This also catches
  // creating irreducible loops, not only rotation.
  if (entry->src->loop_father != exit->dest->loop_father
      && !flow_loop_nested_p (exit->src->loop_father,
                              entry->dest->loop_father))
    {
      cancel_thread (&path, "Path rotates loop");
      return true;
    }

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> (In reply to rguenther@suse.de from comment #24)
> > On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> > > 
> > > --- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> > > > We verify that by simply looking at the loop depth relation of
> > > > the entry and exit of the path.
> > > 
> > > Which seem wrong for the path leaving loop and entering another...
> > 
> > True I guess.  The path should end it the same loop as it starts
> > or end in a loop containing the start loop.  Would have to double
> > check this.
> 
> Yep, done:
> 
>   // The path should either start and end in the same loop or exit the
>   // loop it starts in but never enter a loop.  This also catches
>   // creating irreducible loops, not only rotation.
>   if (entry->src->loop_father != exit->dest->loop_father
>       && !flow_loop_nested_p (exit->src->loop_father,
>                               entry->dest->loop_father))
>     {
>       cancel_thread (&path, "Path rotates loop");
>       return true;
>     }

I suppose it might be more interesting to list what is allowed rather than
what is not.  We want to allow

 flow_loop_nested_p (exit->src->loop_father, entry->dest->loop_father)

plus entry->src->loop_father == exit->dest->loop_father with extra
restrictions on the loop header not being crossed (but entry->src and
exit->dest could be the loop header - in the latter case we create
a subloop when we disambiguate the now multiple latches, in the
former case no harm is done).   The empty latch thing is only relevant
when we allow loop rotation which we don't.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #20)
> (In reply to hubicka from comment #19)

> > The testcase would be
> > 
> > void test ()
> > {
> >         int i;
> >         if (test())
> >           i=0;
> >         else
> >           i=100;
> >         for (;i<100 && bar ();i++)
> >                 do_work ();
> > }

Updated test that compiles:
int check();
int bar ();
void do_work ();

void test ()
{
  int i;
  if (check())
    i=0;
  else
    i=100;
  for (;i<100 && bar ();i++)
    do_work ();
}


> > 
> > Here I think we can thread else path to return w/o any issues with loop
> > nests even with -Os.
> 
> we fail this because
> 
>   // If we crossed a loop into an outer loop without crossing the
>   // latch, this is just an early exit from the loop.
>   if (loops_crossed == 1
>       && !crossed_latch
>       && flow_loop_nested_p (exit->dest->loop_father,
> exit->src->loop_father))
>     return false;
> 
> does not trigger (loops_crossed == 2), and we then run into
> 
> 
>   if (loops_crossed)
>     {
>       cancel_thread (&path, "Path crosses loops");
>       return true;
>     }
> 
> but the loops_crossed stuff is old and not from me, not sure what that's
> useful for.  We could "fix" the accounting with
> 
> diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
> index 8aac733ac25..52ec22e85e1 100644
> --- a/gcc/tree-ssa-threadupdate.c
> +++ b/gcc/tree-ssa-threadupdate.c
> @@ -2810,7 +2810,7 @@ jt_path_registry::cancel_invalid_paths
> (vec<jump_thread_edge *> &path)
>  
>    // If we crossed a loop into an outer loop without crossing the
>    // latch, this is just an early exit from the loop.
> -  if (loops_crossed == 1
> +  if (loops_crossed <= 2
>        && !crossed_latch
>        && flow_loop_nested_p (exit->dest->loop_father,
> exit->src->loop_father))
>      return false;

The above patch doesn't cause any difference in the generated code, at least
for -O2.  I also don't see any more paths registered:

$ grep Registering.jump a.c.*
a.c.126t.thread1:  [1] Registering jump thread: (2, 4) incoming edge;  (4, 8)
nocopy; 
a.c.126t.thread1:  [2] Registering jump thread: (3, 4) incoming edge;  (4, 7)
nocopy; 
a.c.192t.dom3:  [4] Registering jump thread: (6, 5) incoming edge;  (5, 4)
joiner (4, 7) normal; 

> 
> to also allow to thread through a loop path not crossing the latch but
> at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
> be necessary.  It might still prevent us from doing such transforms when
> it involves peeling.

This loops crossing stuff is indeed quite old.  Are you suggesting this as
well?

-  if (loops_crossed)
-    {
-      cancel_thread (&path, "Path crosses loops");
-      return true;
-    }

Which, BTW doesn't change the behavior for this test, but I'm happy to test if
you think it's not necessary.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> 
> --- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #20)
> > (In reply to hubicka from comment #19)
> 
> > > The testcase would be
> > > 
> > > void test ()
> > > {
> > >         int i;
> > >         if (test())
> > >           i=0;
> > >         else
> > >           i=100;
> > >         for (;i<100 && bar ();i++)
> > >                 do_work ();
> > > }
> 
> Updated test that compiles:
> int check();
> int bar ();
> void do_work ();
> 
> void test ()
> {
>   int i;
>   if (check())
>     i=0;
>   else
>     i=100;
>   for (;i<100 && bar ();i++)
>     do_work ();
> }
> 
> 
> > > 
> > > Here I think we can thread else path to return w/o any issues with loop
> > > nests even with -Os.
> > 
> > we fail this because
> > 
> >   // If we crossed a loop into an outer loop without crossing the
> >   // latch, this is just an early exit from the loop.
> >   if (loops_crossed == 1
> >       && !crossed_latch
> >       && flow_loop_nested_p (exit->dest->loop_father,
> > exit->src->loop_father))
> >     return false;
> > 
> > does not trigger (loops_crossed == 2), and we then run into
> > 
> > 
> >   if (loops_crossed)
> >     {
> >       cancel_thread (&path, "Path crosses loops");
> >       return true;
> >     }
> > 
> > but the loops_crossed stuff is old and not from me, not sure what that's
> > useful for.  We could "fix" the accounting with
> > 
> > diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
> > index 8aac733ac25..52ec22e85e1 100644
> > --- a/gcc/tree-ssa-threadupdate.c
> > +++ b/gcc/tree-ssa-threadupdate.c
> > @@ -2810,7 +2810,7 @@ jt_path_registry::cancel_invalid_paths
> > (vec<jump_thread_edge *> &path)
> >  
> >    // If we crossed a loop into an outer loop without crossing the
> >    // latch, this is just an early exit from the loop.
> > -  if (loops_crossed == 1
> > +  if (loops_crossed <= 2
> >        && !crossed_latch
> >        && flow_loop_nested_p (exit->dest->loop_father,
> > exit->src->loop_father))
> >      return false;
> 
> The above patch doesn't cause any difference in the generated code, at least
> for -O2.  I also don't see any more paths registered:

The testcase was for -Os where it makes a difference.  With -Os we
do not perform loop header copying.

> $ grep Registering.jump a.c.*
> a.c.126t.thread1:  [1] Registering jump thread: (2, 4) incoming edge;  (4, 8)
> nocopy; 
> a.c.126t.thread1:  [2] Registering jump thread: (3, 4) incoming edge;  (4, 7)
> nocopy; 
> a.c.192t.dom3:  [4] Registering jump thread: (6, 5) incoming edge;  (5, 4)
> joiner (4, 7) normal; 
> 
> > 
> > to also allow to thread through a loop path not crossing the latch but
> > at least for the issue of "breaking loops" the loops_crossed stuff shouldn't
> > be necessary.  It might still prevent us from doing such transforms when
> > it involves peeling.
> 
> This loops crossing stuff is indeed quite old.  Are you suggesting this as
> well?
> 
> -  if (loops_crossed)
> -    {
> -      cancel_thread (&path, "Path crosses loops");
> -      return true;
> -    }
> 
> Which, BTW doesn't change the behavior for this test, but I'm happy to test if
> you think it's not necessary.

I'd have to go over the function and strip it down to what makes sense to 
me but then you know the thing is fragile, esp. with respect to the
testsuite ;)

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #29 from Martin Liška <marxin at gcc dot gnu.org> ---
As seen here:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.170.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.170.0

the regression is fixed!

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
It likely was the loop header copying missing on cold loops then.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997

--- Comment #31 from hubicka at kam dot mff.cuni.cz ---
> It likely was the loop header copying missing on cold loops then.
Yep. It is good we worked that out.