Skip to content
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

Use PGO for Optimize Bools and If Conversion #113080

Open
a74nh opened this issue Mar 3, 2025 · 4 comments
Open

Use PGO for Optimize Bools and If Conversion #113080

a74nh opened this issue Mar 3, 2025 · 4 comments
Assignees
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone

Comments

@a74nh
Copy link
Contributor

a74nh commented Mar 3, 2025

Both Optmize Bools and If Conversion use hard coded cost values to decide whether to optimize. Instead, when available, both of these should use PGO data make the decision instead.

See #112945 (comment) for discussion

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 3, 2025
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Mar 3, 2025
@neon-sunset
Copy link
Contributor

neon-sunset commented Mar 3, 2025

While looking at this, it would have also been great to finally get rid of if conversion / conditional moves restriction inside the loops, at the very least for simple selects - it emits jumps around single movs which is terrible. It is a sorely outdated restriction which ruins the codegen quality when compared to LLVM despite RyuJIT being capable of producing competitive output.

@a74nh
Copy link
Contributor Author

a74nh commented Mar 3, 2025

While looking at this, it would have also been great to finally get rid of if conversion / conditional moves restriction inside the loops, at the very least for simple selects - it emits jumps around single movs which is terrible. It is a sorely outdated restriction which ruins the codegen quality when compared to LLVM despite RyuJIT being capable of producing competitive output.

Agreed. The code was written very conservatively to make sure there were no perf regressions. It'd be good to re-think the approach.

@vcsjones vcsjones added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Mar 3, 2025
Copy link
Contributor

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

@JulieLeeMSFT JulieLeeMSFT removed the untriaged New issue has not been triaged by the area owner label Mar 6, 2025
@JulieLeeMSFT JulieLeeMSFT added this to the Future milestone Mar 6, 2025
@am11
Copy link
Member

am11 commented Mar 6, 2025

For NativeAOT, the cost is not a concern. dotnet publish can run a second longer if it buys us better codegen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

No branches or pull requests

6 participants