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

Fix a few AMDGPU related issues #52514

Merged
merged 4 commits into from
Sep 12, 2018
Merged

Conversation

DiamondLovesYou
Copy link
Contributor

  • AMDGPU ignores noinline and sadly doesn't clear the attribute when it slaps alwaysinline on everything,
  • an AMDGPU related load bit range metadata assertion,
  • I didn't enable the amdgpu component in the librustc_llvm build script,
  • Add AMDGPU call abi info.

@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 19, 2018
@pietroalbini
Copy link
Member

Ping from triage @eddyb! This PR needs your review.

@pietroalbini pietroalbini added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 30, 2018
@pietroalbini
Copy link
Member

Ping from triage! This PR needs a review, can @eddyb or someone else from @rust-lang/compiler review this?

@estebank
Copy link
Contributor

The code itself looks good to me. Leaving to somebody else that has better knowledge of llvm to chime in and r+.

/// and basically inline everything regardless of our wishes anyway.
/// This causes LLVM validation errors due to the conflicting attributes.
/// Defaults to false.
pub ignore_inline_never: bool,
Copy link
Member

Choose a reason for hiding this comment

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

General strategy is to have is_like_platform for platform-specific handling.

Copy link
Member

Choose a reason for hiding this comment

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

This seems fine to me, though.

Copy link
Member

Choose a reason for hiding this comment

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

Please don't do this, if it's a LLVM-specific temporary hack, add code for it checking e.g. architecture name in triple, to rustc_codegen_llvm.

@@ -564,6 +564,14 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {


pub fn range_metadata(&self, load: ValueRef, range: Range<u128>) {
if self.sess().target.target.arch == "amdgpu" {
// amdgpu/LLVM does something weird and thinks a i64 value is
Copy link
Member

Choose a reason for hiding this comment

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

This sounds like a bug in LLVM. Consider filling a (rust-lang) issue and referencing this piece of code there.

It is definitely desirable to maintain range metadata somehow.

@nagisa
Copy link
Member

nagisa commented Jul 30, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Jul 30, 2018

📌 Commit d992a94 has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 30, 2018
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Jul 30, 2018
Fix a few AMDGPU related issues

* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
@@ -564,6 +564,14 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {


pub fn range_metadata(&self, load: ValueRef, range: Range<u128>) {
if self.sess().target.target.arch == "amdgpu" {
Copy link
Member

Choose a reason for hiding this comment

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

Basically use a check like this instead of ignore_inline_never. Both are LLVM bugs AFAICT.

@eddyb
Copy link
Member

eddyb commented Jul 31, 2018

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 31, 2018
@XAMPPRocky
Copy link
Member

Triage: @DiamondLovesYou We haven't heard from you, Are you able to get back to this?

@DiamondLovesYou
Copy link
Contributor Author

Sorry, I've been out of the States for a while. I've returned but won't be all the way back home till Sunday.

@XAMPPRocky
Copy link
Member

Triage: @DiamondLovesYou Hope your trip went well. Do you have any status updates on this PR?

@DiamondLovesYou
Copy link
Contributor Author

Ready for the second round of reviews. @eddyb @estebank

@pietroalbini pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 27, 2018
@pietroalbini pietroalbini removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 27, 2018
@pietroalbini
Copy link
Member

Ping from triage @eddyb! This PR needs your review.

@TimNN
Copy link
Contributor

TimNN commented Sep 4, 2018

Ping from triage @eddyb / @estebank / @rust-lang/compiler: This PR requires your review.

@estebank
Copy link
Contributor

estebank commented Sep 5, 2018

LGTM but deferring to @eddyb.

@TimNN
Copy link
Contributor

TimNN commented Sep 11, 2018

Ping from triage @eddyb / @rust-lang/compiler: This PR requires your review.

@eddyb
Copy link
Member

eddyb commented Sep 11, 2018

Sorry about the delay, was caught up in edition-related changes.

@bors r+

@bors
Copy link
Contributor

bors commented Sep 11, 2018

📌 Commit 66e8e19 has been approved by eddyb

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 11, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Sep 12, 2018
Fix a few AMDGPU related issues

* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
bors added a commit that referenced this pull request Sep 12, 2018
Rollup of 15 pull requests

Successful merges:

 - #52514 (Fix a few AMDGPU related issues)
 - #53703 (Document .0 to unpack integer from Wrapping)
 - #53777 (Implemented map_or_else for Result<T, E>)
 - #54031 (A few cleanups and minor improvements to rustc_passes)
 - #54046 (Update documentation for fill_buf in std::io::BufRead)
 - #54064 (`&CStr`, not `CStr`, is the counterpart of `&str`)
 - #54072 (Stabilization change for mod.rs)
 - #54073 (docs: Use dollar sign for all bash prompts)
 - #54074 (simplify ordering for Kind)
 - #54085 (Remove documentation about proc_macro being bare-bones)
 - #54087 (rustdoc: Remove generated blanket impls from trait pages)
 - #54106 (Reexport CheckLintNameResult)
 - #54107 (Fix typos in libstd hash map)
 - #54136 (Update LLVM to fix GlobalISel dbg.declare)
 - #54142 (Recover proper regression test for issue #16278.)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Sep 12, 2018

⌛ Testing commit 66e8e19 with merge 8586ec6...

@bors bors merged commit 66e8e19 into rust-lang:master Sep 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

9 participants