BSD Commit Log Search

Update OB name from `type` to `callee_type`.

Created using spr 1.3.6-beta.1

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.6-beta.1

[skip ci]

Update LTO compilation CodeGen flag for call-graph-section.

Created using spr 1.3.6-beta.1

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.6-beta.1

[skip ci]

rebase

Created using spr 1.3.4

Rebase, address comments, remove some extra graph-related code

Created using spr 1.3.5

rebase

Created using spr 1.3.4

Merge branch 'main' into users/chapuni/yaml/newgen

Conflicts:
        llvm/test/tools/llvm-cov/Inputs/branch-logical-mixed.cpp
        llvm/test/tools/llvm-cov/Inputs/branch-macros.cpp

Merge branch 'users/meinersbur/flang_runtime' into users/meinersbur/flang_runtime_shared

Merge branch 'users/meinersbur/flang_runtime_move-files' into users/meinersbur/flang_runtime

Merge branch 'main' into users/meinersbur/flang_runtime_move-files

Revert "[RISCV] Default to MicroOpBufferSize = 1 for scheduling purposes (#126608)" and follow up commit.

This reverts commit 9cc8442a2b438962883bbbfd8ff62ad4b1a2b95d.
This reverts commit 859c871184bdfdebb47b5c7ec5e59348e0534e0b.

A performance regression was reported on the original review.  There appears
to have been an unexpected interaction here.  Reverting during investigation.

[RISCV] Default to MicroOpBufferSize = 1 for scheduling purposes (#126608)

This change introduces a default schedule model for the RISCV target
which leaves everything unchanged except the MicroOpBufferSize. The
default value of this flag in NoSched is 0. Both configurations
represent in order cores (i.e. no reorder window), the difference
between them comes down to whether heuristics other than latency are
allowed to apply. (Implementation details below)

I left the processor models which explicitly set MicroOpBufferSize=0
unchanged in this patch, but strongly suspect we should change those
too. Honestly, I think the LLVM wide default for this flag should be
changed, but don't have the energy to manage the updates for all
targets.

Implementation wise, the effect of this change is that schedule units
which are ready to run *except that* one of their predecessors may not
have completed yet are added to the Available list, not the Pending one.
The result of this is that it becomes possible to chose to schedule a

    [18 lines not shown]

Merge branch 'users/meinersbur/flang_runtime_shared' into users/meinersbur/flang_runtime_remove-FLANG_INCLUDE_RUNTIME

Merge branch 'users/meinersbur/flang_runtime' into users/meinersbur/flang_runtime_shared

Merge branch 'users/meinersbur/flang_runtime_move-files' into users/meinersbur/flang_runtime

Merge commit '660cdace559a8dbe44ebf2222b854bf3f39a5f62' into users/meinersbur/flang_runtime_move-files

Revert "[RISCV] Default to MicroOpBufferSize = 1 for scheduling purposes (#126608)" and follow up commit.

This reverts commit 9cc8442a2b438962883bbbfd8ff62ad4b1a2b95d.
This reverts commit 859c871184bdfdebb47b5c7ec5e59348e0534e0b.

A performance regression was reported on the original review.  There appears
to have been an unexpected interaction here.  Reverting during investigation.

Rebase

Created using spr 1.3.5

rebase

Created using spr 1.3.4

relnote

Created using spr 1.3.4

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.4

[skip ci]

[RISCV] Default to MicroOpBufferSize = 1 for scheduling purposes (#126608)

This change introduces a default schedule model for the RISCV target
which leaves everything unchanged except the MicroOpBufferSize. The
default value of this flag in NoSched is 0. Both configurations
represent in order cores (i.e. no reorder window), the difference
between them comes down to whether heuristics other than latency are
allowed to apply. (Implementation details below)

I left the processor models which explicitly set MicroOpBufferSize=0
unchanged in this patch, but strongly suspect we should change those
too. Honestly, I think the LLVM wide default for this flag should be
changed, but don't have the energy to manage the updates for all
targets.

Implementation wise, the effect of this change is that schedule units
which are ready to run *except that* one of their predecessors may not
have completed yet are added to the Available list, not the Pending one.
The result of this is that it becomes possible to chose to schedule a

    [18 lines not shown]

Rebase on top of main.

Created using spr 1.3.6-beta.1

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.6-beta.1

[skip ci]

Rebase on top of main.

Created using spr 1.3.6-beta.1

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.6-beta.1

[skip ci]

Rebase on top of main.

Created using spr 1.3.6-beta.1

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.6-beta.1

[skip ci]

Rebase on top of main.

Created using spr 1.3.6-beta.1