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

Avoid unnecessary allocas for indirect function arguments #44573

Merged
merged 1 commit into from
Oct 18, 2017

Conversation

dotdash
Copy link
Contributor

@dotdash dotdash commented Sep 14, 2017

The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@eddyb
Copy link
Member

eddyb commented Sep 14, 2017

LGTM. r? @michaelwoerister

@alexcrichton alexcrichton added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 14, 2017
@michaelwoerister
Copy link
Member

@bors r+

Thanks @dotdash!

@bors
Copy link
Contributor

bors commented Sep 15, 2017

📌 Commit ed7a7cf has been approved by michaelwoerister

@michaelwoerister michaelwoerister 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 15, 2017
TimNN added a commit to TimNN/rust that referenced this pull request Sep 17, 2017
Avoid unnecessary allocas for indirect function arguments

The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.
@TimNN
Copy link
Contributor

TimNN commented Sep 17, 2017

This likely caused rollup #44649 to fail with the following error on x86_64-gnu-debug:

[00:27:41] rustc: /checkout/src/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp:295: void llvm::DwarfExpression::addFragmentOffset(const llvm::DIExpression*): Assertion `FragmentOffset >= OffsetInBits && "overlapping or duplicate fragments"' failed.
[00:27:41] error: Could not compile `std`.

(x86_64-gnu-debug succeeded in rollup #44652, who's only difference to #44649 was that this PR was excluded)

@bors
Copy link
Contributor

bors commented Sep 17, 2017

⌛ Testing commit ed7a7cf with merge ee179583d630a07cf0009739c6edbc61ada961a8...

@arielb1
Copy link
Contributor

arielb1 commented Sep 17, 2017

@bors r-

@arielb1
Copy link
Contributor

arielb1 commented Sep 17, 2017

@bors retry

@arielb1
Copy link
Contributor

arielb1 commented Sep 17, 2017

Turns out leaving LLVM assertions disabled isn't a good idea when working with LLVM.

@michaelwoerister
Copy link
Member

Is there anything we can do about this? Or does this just not work in the general case?

@dotdash
Copy link
Contributor Author

dotdash commented Sep 19, 2017

Looks like an LLVM bug which is only triggered by this change. The jump threading pass duplicates an dbg.declare intrinsic, causing the same fragment to be declared twice and triggering the assertion. I asked on the LLVM ML about it.

http://lists.llvm.org/pipermail/llvm-dev/2017-September/117575.html

@eddyb
Copy link
Member

eddyb commented Sep 19, 2017

@dotdash It wouldn't be the first time LLVM mangles non-trivial debuginfo annotations.

@michaelwoerister
Copy link
Member

@dotdash ❤️

@arielb1 arielb1 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 Sep 19, 2017
@aidanhs
Copy link
Member

aidanhs commented Sep 28, 2017

For triage clarity, where is this up to? Is there a patch making its way upstream (and if so, is there a link to the LLVM phabricator so we can track it)?

@dotdash
Copy link
Contributor Author

dotdash commented Oct 4, 2017

Sorry, I've been unable to get back to this earlier. Upstream patch is at https://reviews.llvm.org/D38540

@dotdash
Copy link
Contributor Author

dotdash commented Oct 11, 2017

Updated to include the necessary LLVM update and added a second commit to avoid even more copies and fix a debug info oddity/bug.

@dotdash dotdash force-pushed the dbg_bloat branch 3 times, most recently from b18ed29 to 43c4589 Compare October 13, 2017 14:07
@bors
Copy link
Contributor

bors commented Oct 14, 2017

☔ The latest upstream changes (presumably #45162) made this pull request unmergeable. Please resolve the merge conflicts.

@dotdash
Copy link
Contributor Author

dotdash commented Oct 16, 2017

Rebased and backed out the commit that was failing earlier. Should be good to go now.

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 16, 2017
@@ -1,4 +1,4 @@
# If this file is modified, then llvm will be (optionally) cleaned and then rebuilt.
# The actual contents of this file do not matter, but to trigger a change on the
# build bots then the contents should be changed so git updates the mtime.
2017-07-18
2017-10-10
Copy link
Member

Choose a reason for hiding this comment

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

Do you need to change this?

Copy link
Contributor

Choose a reason for hiding this comment

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

There was an LLVM rebuild race.

@arielb1
Copy link
Contributor

arielb1 commented Oct 18, 2017

r+ with the llvm rebuild trigger removed - it is not needed any more because someone else updated our LLVM.

@kennytm kennytm 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-review Status: Awaiting review from the assignee but also interested parties. labels Oct 18, 2017
@michaelwoerister
Copy link
Member

👍

The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.
@dotdash
Copy link
Contributor Author

dotdash commented Oct 18, 2017

@bors r=arielb1

@bors
Copy link
Contributor

bors commented Oct 18, 2017

📌 Commit 6bfecd4 has been approved by arielb1

@kennytm kennytm 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 18, 2017
@bors
Copy link
Contributor

bors commented Oct 18, 2017

⌛ Testing commit 6bfecd4 with merge fc208bb...

bors added a commit that referenced this pull request Oct 18, 2017
Avoid unnecessary allocas for indirect function arguments

The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.
@bors
Copy link
Contributor

bors commented Oct 18, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing fc208bb to master...

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.