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

LLVM globals corresponding to miri allocations should be named alloc123. #69134

Closed
eddyb opened this issue Feb 13, 2020 · 5 comments
Closed

LLVM globals corresponding to miri allocations should be named alloc123. #69134

eddyb opened this issue Feb 13, 2020 · 5 comments
Assignees
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Feb 13, 2020

That is, if -Zfewer-names is false (usually only because of --emit=llvm-ir), we should use the same name for LLVM globals we generate out of miri allocs as #67133 does in MIR output (allocN).

This way, we can easily see the mapping between MIR and LLVM IR (and it shouldn't be any costlier for regular compilation, which would continue to use unnamed globals).

Relevant code (btw this could probably use extra caching keyed on AllocId?):

Some(GlobalAlloc::Memory(alloc)) => {
let init = const_alloc_to_llvm(self, alloc);
if alloc.mutability == Mutability::Mut {
self.static_addr_of_mut(init, alloc.align, None)
} else {
self.static_addr_of(init, alloc.align, None)
}
}

cc @rust-lang/wg-mir-opt @bjorn3

This issue has been assigned to @chrissimpkins via this comment.

@oli-obk oli-obk added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Feb 13, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Feb 13, 2020

Kinda vague instructions:

  1. Replace the None for the static_addr_of_mut and static_addr_of call with a Some by creating the name via ptr.alloc_id.to_string().
  2. Run all codegen tests and adjust them as necessary.

@jonas-schievink jonas-schievink added A-codegen Area: Code generation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Feb 13, 2020
@chrissimpkins
Copy link
Member

@rustbot claim

@chrissimpkins
Copy link
Member

chrissimpkins commented Feb 14, 2020

#69155

Mind having a look at the updated checks? They pass on local stage 1 tests of test/codegen, but I can't verify that they are valid expected values.

@kumar4467

This comment has been minimized.

bors added a commit that referenced this issue Mar 13, 2020
Add support for LLVM globals corresponding to miri allocations should be named alloc123

Adds support for this request from @eddyb in #69134:

> That is, if -Zfewer-names is false (usually only because of --emit=llvm-ir), we should use the same name for LLVM globals we generate out of miri allocs as #67133 does in MIR output (allocN).
>
>This way, we can easily see the mapping between MIR and LLVM IR (and it shouldn't be any costlier for regular compilation, which would continue to use unnamed globals).

r? @eddyb
cc @oli-obk
@chrissimpkins
Copy link
Member

merged to master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants