Skip to content

pre-commit: PR143020 #2426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

pre-commit: PR143020 #2426

wants to merge 2 commits into from

Conversation

dtcxzyw
Copy link
Owner

@dtcxzyw dtcxzyw commented Jun 11, 2025

Link: llvm/llvm-project#143020
Requested by: @nikic

@github-actions github-actions bot mentioned this pull request Jun 11, 2025
@dtcxzyw
Copy link
Owner Author

dtcxzyw commented Jun 11, 2025

Diff mode

runner: ariselab-64c-docker
baseline: llvm/llvm-project@0c62571
patch: llvm/llvm-project#143020
sha256: 39c25067060921acec55fe4455507f1446c8bd92adad5b13db6f709b71122bb0
commit: eb167e8

3 files changed, 1375 insertions(+), 1376 deletions(-)

Improvements:
Regressions:
  instcombine.NumDeadInst 45401612 -> 45401609 -0.00%
  instcombine.NumCombined 131974382 -> 131974378 -0.00%

2 2 bench/flac/optimized/replaygain.ll

Copy link
Contributor

Here is a summary of the most significant changes in the provided LLVM IR diff:

  1. Reordering of smax and select operations:
    The order of two key operations—llvm.smax.i32 and select—has been swapped. Previously, smax was applied first, and its result was used in the select. Now, the select is performed first, and its result is then passed to smax.

  2. Modification of operand to smax:
    As a result of the reordering, the second operand of the smax call changes from %104 (which was the result of the previous select) to %104_new, which now comes from the select instruction that precedes it. This alters the logic for determining the maximum value.

  3. Removal of dependency on intermediate variable .10136190 in select:
    The select instruction no longer uses the intermediate value %.10136190 as one of its possible outcomes. Instead, it now chooses directly between 2147483647 (if %102 is true) and %103.

  4. Change in control flow/data flow logic:
    While there's no explicit change to control flow, the reordering of operations affects how values are computed and selected, potentially altering performance characteristics or handling of edge cases (e.g., signed integer overflow).

  5. Potential impact on behavior with extreme values:
    Since %103 comes from llvm.abs.i32 with i1 true (which indicates "noundef"), and %102 checks for INT_MIN, this revised logic may handle the edge case of input -2147483648 differently when computing the max after absolute value.

High-Level Overview:

The patch modifies how maximum value selection is performed by changing the sequence of operations involving absolute value, selection, and signed maximum. This could affect both correctness (especially in edge cases) and optimization potential (e.g., simplification opportunities for the optimizer).

model: qwen-plus-latest
CompletionUsage(completion_tokens=464, prompt_tokens=552, total_tokens=1016, completion_tokens_details=None, prompt_tokens_details=None)

@dtcxzyw dtcxzyw closed this Aug 2, 2025
@dtcxzyw dtcxzyw deleted the test-run15594563879 branch August 2, 2025 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants