Skip to content

Move scalar_to_backend to ssa #142960

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jun 24, 2025

r? @GuillaumeGomez @antoyo

I think that should make it much more maintainable going forward

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 24, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 24, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.


fn get_value_name(&self, _val: Self::Value) -> &[u8] {
// TODO(antoyo)
&[]
Copy link
Member

Choose a reason for hiding this comment

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

I should really finish to add this API in libgccjit. ^^'

@GuillaumeGomez
Copy link
Member

Thanks a lot, it will help making our life easier in the GCC backend!

Just waiting for @antoyo to confirm it's good for him as well then we can r+.

Comment on lines +70 to +78
Scalar::Int(int) => {
let data = int.to_bits(layout.size(self));
let llval = self.const_uint_big(self.type_ix(bitsize), data);
if matches!(layout.primitive(), Primitive::Pointer(_)) {
self.const_int_to_ptr(llval, llty)
} else {
self.const_bitcast(llval, llty)
}
}
Copy link
Contributor

@antoyo antoyo Jun 24, 2025

Choose a reason for hiding this comment

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

This is very likely to break cg_gcc since the bitcast doesn't work in const context (see comment in the original implementation).
I can check if I could make it work in const context in libgccjit if needed.

Nice refactor, btw!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

can we cheat and do the bitsize > 1 && ty.is_integral() && bytesize as u32 == ty.get_size() check within the cg_gcc const_bitcast impl?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll have to thing about whether this could break other things: if that ever gets called with a value of a struct type, for instance, I assume this would break.
Would you have access to bytesize?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we can very readily provide it, we're in control of this method and llvm will just ignore it

Copy link
Contributor

Choose a reason for hiding this comment

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

Let me try locally since I'm concerned that this will break other things.

Copy link
Contributor

Choose a reason for hiding this comment

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

we can very readily provide it, we're in control of this method and llvm will just ignore it

So, your plan would be to change all other calls and possibly the API of the functions calling const_bitcast to add the missing parameters if needed?
Or will you change the other calls so that they call another function than const_bitcast?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no rush, we can let this PR sit for a while.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, your plan would be to change all other calls and possibly the API of the functions calling const_bitcast to add the missing parameters if needed?
Or will you change the other calls so that they call another function than const_bitcast?

ah yea we should probably just add a new function for this specific case and have llvm forward to const_bitcast and gcc do the checks and fallback logic

Copy link
Contributor

@antoyo antoyo Jun 24, 2025

Choose a reason for hiding this comment

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

Ok, good.
We're in the process of adding more tests for cg_gcc in the Rust CI (will try to open an MCP for this soon), so this should make this kind of refactor much easier.

/// Create a global constant.
///
/// The returned global variable is a pointer in the default address space for globals.
fn static_addr_of_impl(&self, cv: Self::Value, align: Align, kind: Option<&str>)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe call this static_addr_of_const?

Copy link
Member

Choose a reason for hiding this comment

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

Also it looks like the kind argument is always None, so you can remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

unfortunately vtables need this at present to achieve

// Make sure that vtables don't have the unnamed_addr attribute when debuginfo is enabled.

and since vtables are const, and that logic calls the mut logic before marking the alloc as const, we need to keep it around everywhere. There's likely things to improve here, but that should probably be its own PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah fun, we only do that in some vtable paths, but not in the one in scalar_to_backend

-> Self::Value;

/// Same as `static_addr_of_impl`, but does not mark the static as immutable
fn static_addr_of_mut(&self, cv: Self::Value, align: Align, kind: Option<&str>) -> Self::Value;
Copy link
Member

Choose a reason for hiding this comment

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

Same here. kind is always None.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants