Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. by eddyb · Pull Request #40367 · rust-lang/rust

eddyb · 2017-03-08T18:26:15Z

These two small changes fixedef1c/libfringe#68:

Don't emit ZST allocas, such as when returning ()
Don't emit a branch from LLVM's entry block to MIR's START_BLOCK unless needed
- That is, if a loop branches back to it, although I'm not sure that's even valid MIR

rust-highfive · 2017-03-08T18:26:27Z

r? @nrc

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

nagisa

LGTM.

nagisa · 2017-03-08T18:36:23Z

- bug!("cannot generate operand from rvalue {:?}", rvalue);
-
+ // According to `rvalue_creates_operand`, only ZST
+ // aggregate rvalues are allowed to be operands.


(debug) assertion would be nice here. It is not unlikely for somebody to edit some interaction between some rvalue_creates_operand and this function in a wrong way and an assertion here would catch it.

I had one! It's now in OperandRef::new_zst.

eddyb · 2017-03-08T18:43:18Z

@bors r=nagisa

bors · 2017-03-08T18:43:19Z

📌 Commit df60044 has been approved by nagisa

bors · 2017-03-09T10:43:11Z

🔒 Merge conflict

alexcrichton · 2017-03-09T15:04:59Z

@bors: retry

Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. These two small changes fixedef1c/libfringe#68: * Don't emit ZST allocas, such as when returning `()` * Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed * That is, if a loop branches back to it, although I'm not sure that's even valid MIR

alexcrichton · 2017-03-10T16:21:17Z

@bors: r=nagisa

bors · 2017-03-10T16:21:18Z

📌 Commit d8ca084 has been approved by nagisa

Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. These two small changes fixedef1c/libfringe#68: * Don't emit ZST allocas, such as when returning `()` * Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed * That is, if a loop branches back to it, although I'm not sure that's even valid MIR

Rollup of 38 pull requests - Successful merges: #39202, #39820, #39918, #39921, #40092, #40146, #40199, #40225, #40239, #40257, #40259, #40261, #40277, #40278, #40287, #40297, #40311, #40315, #40319, #40324, #40336, #40340, #40344, #40345, #40367, #40369, #40372, #40373, #40379, #40385, #40386, #40389, #40400, #40404, #40410, #40422, #40423, #40424 - Failed merges: #40220, #40329, #40426

Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. These two small changes fixedef1c/libfringe#68: * Don't emit ZST allocas, such as when returning `()` * Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed * That is, if a loop branches back to it, although I'm not sure that's even valid MIR

arielb1 · 2017-03-11T19:56:32Z

Eh, @bors r-

Better that @eddyb add a tester for i686-gnu-noopt.

Test failure:

---- [debuginfo-gdb] debuginfo-gdb/macro-stepping.rs stdout ----
NOTE: compiletest thinks it is using GDB without native rust support
NOTE: compiletest thinks it is using GDB version 7011001
error: line not found in debugger output: [...]#inc-loc1[...]

bors · 2017-03-20T21:06:01Z

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

eddyb · 2017-03-21T16:16:57Z

Looks like -noopt isn't needed, this repros:

./x.py test --stage 1 src/test/debuginfo --test-args macro-stepping --target i686-unknown-linux-gnu

eddyb · 2017-04-12T15:52:52Z

I've gradually transformed the LLVM IR from Rust to match the LLVM IR from Clang.
This is what I am left with, test.c.ll working as expected, while test.rs.ll not:

--- test.c.ll 2017-04-12 15:58:31.236264978 +0000+++ test.rs.ll 2017-04-12 15:59:02.302421857 +0000@@ -29 +29 @@-!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 3.9.1 (tags/RELEASE_391/final)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "rustc version 1.18.0-dev (57ca703dc 2017-04-11)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)

EDIT: Shorter diff, !llvm.ident does not appear relevant.
EDIT2: GDB harcodes startswith (COMPUNIT_PRODUCER (cust), "clang ").

eddyb · 2017-04-12T17:02:37Z

So it turns out that LLVM produces this (for a main that starts with a call):

main: .loc 150 pushl %ebp movl %esp, %ebp .loc 165 prologue_end subl$8, %esp calll included

GDB is capable of determining that the last instruction in the prologue is subl.
However, the .loc is before that instruction. If the .loc is moved/duplicated to after subl (i.e. just before calll), then GDB will properly break-on-line (6) at the calll instruction.

eddyb · 2017-04-12T17:45:29Z

@bors r=nagisa

bors · 2017-04-12T17:45:30Z

📌 Commit 9b5c577 has been approved by nagisa

bors · 2017-04-12T18:16:15Z

⌛ Testing commit 9b5c577 with merge 3ee3088...

bors · 2017-04-12T19:58:08Z

💔 Test failed - status-travis

eddyb · 2017-04-12T20:15:19Z

@bors retry

OpenSSL on OSX failed to compile?

bors · 2017-04-12T22:54:16Z

⌛ Testing commit 9b5c577 with merge 8e25752...

bors · 2017-04-13T00:28:06Z

💔 Test failed - status-travis

alexcrichton · 2017-04-13T03:09:04Z

@bors: retry * openssl compile failure - #40417

…

On Wed, Apr 12, 2017 at 7:28 PM, bors ***@***.***> wrote: 💔 Test failed - status-travis <https://travis-ci.org/rust-lang/rust/builds/221539796> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40367 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95HcODQfcDRwRRoWPvfYU-V0dvhrEks5rvWwmgaJpZM4MXIqb> .

bors · 2017-04-13T04:22:16Z

⌛ Testing commit 9b5c577 with merge 1470a1a...

bors · 2017-04-13T05:28:08Z

💔 Test failed - status-travis

arielb1 · 2017-04-13T07:12:34Z

Musl segfault:

Spurious segfault in tests for musl #38618

@bors retry

bors · 2017-04-13T11:47:38Z

⌛ Testing commit 9b5c577 with merge 43ef63d...

Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. These two small changes fixedef1c/libfringe#68: * Don't emit ZST allocas, such as when returning `()` * Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed * That is, if a loop branches back to it, although I'm not sure that's even valid MIR

bors · 2017-04-13T14:22:18Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nagisa
Pushing 43ef63d to master...

rust-highfive assigned nrc Mar 8, 2017

nagisa approved these changes Mar 8, 2017
View reviewed changes

arielb1 mentioned this pull request Mar 9, 2017
Rollup of 12 pull requests #40403
Closed

alexcrichton mentioned this pull request Mar 10, 2017
Rollup of 36 pull requests #40418
Closed

alexcrichton force-pushed the naked-cruft branch from df60044 to d8ca084Compare March 10, 2017 16:21

alexcrichton mentioned this pull request Mar 10, 2017
Rollup of 35 pull requests #40420
Closed

alexcrichton mentioned this pull request Mar 10, 2017
Rollup of 38 pull requests #40432
Merged

arielb1 mentioned this pull request Mar 11, 2017
Rollup of 13 pull requests #40440
Closed

eddyb mentioned this pull request Mar 22, 2017
Naked functions with parameters generate load/store instructions in debug mode #34043
Closed

eddyb mentioned this pull request Apr 12, 2017
GDB hardcodes startswith(producer, "clang ") to cope with LLVM debug line info in prologues. #41252
Open

eddyb added 2 commits April 12, 2017 20:20

rustc_trans: don't emit ZST allocas that are only assigned to.
cb3c4d0

rustc_trans: avoid a separate entry BB if START_BLOCK has no backedges.
9b5c577

eddyb force-pushed the naked-cruft branch from d8ca084 to 9b5c577Compare April 12, 2017 17:44

bors merged commit 9b5c577 into rust-lang:masterApr 13, 2017

eddyb deleted the naked-cruft branch April 13, 2017 14:31

eddyb mentioned this pull request May 7, 2017
AddressSanitizer: false positives with structs/tuples that end with Zero Sized Types #39882
Closed

Uh oh!

Uh oh!

Conversation

eddyb commented Mar 8, 2017

Uh oh!

rust-highfive commented Mar 8, 2017

Uh oh!

nagisa left a comment

Choose a reason for hiding this comment

Uh oh!

nagisaMar 8, 2017

Choose a reason for hiding this comment

Uh oh!

eddybMar 8, 2017

Choose a reason for hiding this comment

Uh oh!

eddyb commented Mar 8, 2017

Uh oh!

bors commented Mar 8, 2017

Uh oh!

bors commented Mar 9, 2017

Uh oh!

alexcrichton commented Mar 9, 2017

Uh oh!

alexcrichton commented Mar 10, 2017

Uh oh!

bors commented Mar 10, 2017

Uh oh!

arielb1 commented Mar 11, 2017

Uh oh!

bors commented Mar 20, 2017

Uh oh!

eddyb commented Mar 21, 2017

Uh oh!

eddyb commented Apr 12, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eddyb commented Apr 12, 2017

Uh oh!

eddyb commented Apr 12, 2017

Uh oh!

bors commented Apr 12, 2017

Uh oh!

bors commented Apr 12, 2017

Uh oh!

bors commented Apr 12, 2017

Uh oh!

eddyb commented Apr 12, 2017

Uh oh!

bors commented Apr 12, 2017

Uh oh!

bors commented Apr 13, 2017

Uh oh!

alexcrichton commented Apr 13, 2017 via email

Uh oh!

bors commented Apr 13, 2017

Uh oh!

bors commented Apr 13, 2017

Uh oh!

arielb1 commented Apr 13, 2017

Uh oh!

bors commented Apr 13, 2017

Uh oh!

bors commented Apr 13, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

eddyb commented Apr 12, 2017•
edited
Loading