Revert "[Mips] Fix missing sign extension in expansion of sub-word atomic max (#77072)"

[nikic]

These changes caused correctness regressions observed in Rust, see #77072 (comment) and following. Revert the incorrect changes from the release branch.

This reverts commit 0e501db.
This reverts commit fbb27d1.

[dianqk]

LGTM.

[tstellar]

Hi @nikic (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix.

[dianqk]

Hi @nikic (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix.

I'm not sure if this description is accurate:
Fix the issue where the atomic instructions on MIPS do not return the correct results.

cc @topperc

[topperc]

Hi @nikic (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix.

I'm not sure if this description is accurate: Fix the issue where the atomic instructions on MIPS do not return the correct results.

cc @topperc

Probably should mention min/max specifically.

[nikic]

I'd also add that this fixes a regression from a previous LLVM 18 point release:

Fix regressions introduced in LLVM 18.1.3 in MIPS atomicrmw min/max codegen.

[yingopq]

@nikic Hi, have you not reverted those two patches in main branch yet? I plan to submit new patch which has addressed this issue.

[nikic]

@yingopq The patches are not reverted in main, so you can base your fix on top of the existing changes (or revert them as part of your PR, if that's easier?)

[yingopq]

@yingopq The patches are not reverted in main, so you can base your fix on top of the existing changes (or revert them as part of your PR, if that's easier?)

Should it be consistent with the release branch, so that it is more convenient to merge into the release branch?

[dianqk]

@yingopq The patches are not reverted in main, so you can base your fix on top of the existing changes (or revert them as part of your PR, if that's easier?)

Should it be consistent with the release branch, so that it is more convenient to merge into the release branch?

Maybe you can revert them in your new PR, then we can use rebase and push to merge your PR.
Or we can also revert this PR (#88818) and cherry-pick your new patch in release/18.x.

[nikic]

Given that this change has already caused two distinct bugs, I don't think we will accept a backport for it anyway, so don't worry about the release branch.