Skip to content

[GlobalMerge][NFC] Skip sorting by profitability when it is not needed #124146

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

Merged
merged 2 commits into from
Jan 24, 2025

Conversation

michaelmaitland
Copy link
Contributor

We were previously sorting by profitability even if we were choosing to merge all globals together, which is not impacted by UsedGlobalSet order.

We can also remove iteration of UsedGlobalSets in reverse order in both cases. In the first csae, the order does not matter. In the second case, we just sort by the order we need instead of sorting in the opposite direction and calling reverse.

This change should only be an improvement on compile time. I have not measured it, but I think it would never make things worse.

We were previously sorting by profitability even if we were choosing to merge
all globals together, which is not impacted by UsedGlobalSet order.

We can also remove iteration of UsedGlobalSets in reverse order in both cases.
In the first csae, the order does not matter. In the second case, we just sort
by the order we need instead of sorting in the opposite direction and calling
reverse.

This change should only be an improvement on compile time. I have not measured
it, but I think it would never make things worse.
Copy link

github-actions bot commented Jan 23, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Contributor

@wangpc-pp wangpc-pp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense, LGTM!

@michaelmaitland michaelmaitland merged commit e5e55c0 into llvm:main Jan 24, 2025
8 checks passed
@michaelmaitland michaelmaitland deleted the gm-skip-sort branch January 24, 2025 14:08
@jyknight
Copy link
Member

This was not NFC: it causes the comparator not have strict-weak-ordering, because comp(a, b) && comp(b, a) can now be true. Most immediately, this triggers an assert with the test llvm/test/CodeGen/AArch64/global-merge-group-by-use.ll when run under a hardened stdlib (assertion !__comp_(__l, __r) failed: Comparator does not induce a strict weak ordering).

I believe you meant to use > instead of >=.

@michaelmaitland
Copy link
Contributor Author

This was not NFC: it causes the comparator not have strict-weak-ordering, because comp(a, b) && comp(b, a) can now be true. Most immediately, this triggers an assert with the test llvm/test/CodeGen/AArch64/global-merge-group-by-use.ll when run under a hardened stdlib (assertion !__comp_(__l, __r) failed: Comparator does not induce a strict weak ordering).

I believe you meant to use > instead of >=.

The assertion failure didn’t show up in pre-commit CI and I haven’t gotten any build bot failures. So thanks for pointing it out. Can you please revert or make the change to > for me as I am currently AFK for the night?

Thanks.

@topperc
Copy link
Collaborator

topperc commented Jan 25, 2025

It's still not NFC with >. stable_sort won't change the order of equal elements. If there are multiple equal elements reverse would visit the later ones first. Removing the reverse means the earliest equal element first.

jyknight added a commit that referenced this pull request Jan 25, 2025
…ot needed" (#124411)

Reverts #124146 -- new comparator is not a strict-weak
as required by stable_sort.

Co-authored-by: Michael Maitland <[email protected]>
github-actions bot pushed a commit to arm/arm-toolchain that referenced this pull request Jan 25, 2025
…hen it is not needed" (#124411)

Reverts llvm/llvm-project#124146 -- new comparator is not a strict-weak
as required by stable_sort.

Co-authored-by: Michael Maitland <[email protected]>
michaelmaitland added a commit that referenced this pull request Jan 27, 2025
…ot needed"

Relands #124146 but without changes to the sorting algorithm and the following
reverse.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants