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

trans: Move rust_try into the compiler #27176

Merged
merged 1 commit into from Jul 22, 2015

Conversation

Projects
None yet
9 participants
@alexcrichton
Member

alexcrichton commented Jul 21, 2015

This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:

  • LLVM changes its IR syntax from time to time, so it's very difficult to
    have these files build across many LLVM versions simultaneously. We'll likely
    want to retain this ability for quite some time into the future.
  • The implementation of these files is closely tied to the compiler and runtime
    itself, so it makes sense to fold it into a location which can do more
    platform-specific checks for various implementation details (such as MSVC 32
    vs 64-bit).
  • This removes LLVM as a build-time dependency of the standard library. This may
    end up becoming very useful if we move towards building the standard library
    with Cargo.

In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 21, 2015

Collaborator

r? @pcwalton

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

Collaborator

rust-highfive commented Jul 21, 2015

r? @pcwalton

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 21, 2015

Member

r? @brson

cc @rust-lang/compiler (my knowledge of trans is pretty bad and I may have done egregious things)

Member

alexcrichton commented Jul 21, 2015

r? @brson

cc @rust-lang/compiler (my knowledge of trans is pretty bad and I may have done egregious things)

@rust-highfive rust-highfive assigned brson and unassigned pcwalton Jul 21, 2015

Show outdated Hide outdated src/librustc_trans/trans/intrinsic.rs
}
// MSVC's definition of the `rust_try` function. The exact implementation here
// is a little different than the GNU (standard) version below, not ony because

This comment has been minimized.

@Aatch

Aatch Jul 21, 2015

Contributor

"ony" -> "only"

@Aatch

Aatch Jul 21, 2015

Contributor

"ony" -> "only"

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 21, 2015

Contributor

@bors r+

Contributor

brson commented Jul 21, 2015

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 21, 2015

Contributor

📌 Commit 6046fb7 has been approved by brson

Contributor

bors commented Jul 21, 2015

📌 Commit 6046fb7 has been approved by brson

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 21, 2015

Contributor

Awesome patch.

Contributor

brson commented Jul 21, 2015

Awesome patch.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 21, 2015

Member

@bors: r=brson

Member

alexcrichton commented Jul 21, 2015

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 21, 2015

Contributor

📌 Commit 970a3ca has been approved by brson

Contributor

bors commented Jul 21, 2015

📌 Commit 970a3ca has been approved by brson

Show outdated Hide outdated src/librustc_trans/trans/intrinsic.rs
false);
// Define the "inner try" shim
let rust_try_inner = declare::declare_internal_rust_fn(ccx,

This comment has been minimized.

@nagisa

nagisa Jul 21, 2015

Contributor

If you are “defining” the shim, declare::define_internal_rust_fn should be used.

@nagisa

nagisa Jul 21, 2015

Contributor

If you are “defining” the shim, declare::define_internal_rust_fn should be used.

Show outdated Hide outdated src/librustc_trans/trans/intrinsic.rs
});
// Define the "outer try" shim.
let rust_try = declare::declare_internal_rust_fn(ccx, "__rust_try",

This comment has been minimized.

@nagisa

nagisa Jul 21, 2015

Contributor

ditto.

@nagisa

nagisa Jul 21, 2015

Contributor

ditto.

@@ -120,7 +120,8 @@ extern "C" void LLVMAddDereferenceableCallSiteAttr(LLVMValueRef Instr, unsigned
idx, B)));
}
extern "C" void LLVMAddFunctionAttribute(LLVMValueRef Fn, unsigned index, uint64_t Val) {
extern "C" void LLVMAddFunctionAttribute(LLVMValueRef Fn, unsigned index,

This comment has been minimized.

@nagisa

nagisa Jul 21, 2015

Contributor

nit: doesn’t seem to be necessary change.

@nagisa

nagisa Jul 21, 2015

Contributor

nit: doesn’t seem to be necessary change.

trans: Move rust_try into the compiler
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:

* LLVM changes its IR syntax from time to time, so it's very difficult to
  have these files build across many LLVM versions simultaneously. We'll likely
  want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
  itself, so it makes sense to fold it into a location which can do more
  platform-specific checks for various implementation details (such as MSVC 32
  vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
  end up becoming very useful if we move towards building the standard library
  with Cargo.

In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
Member

alexcrichton commented Jul 21, 2015

@bors: r=brson c35b2bd

bors added a commit that referenced this pull request Jul 22, 2015

Auto merge of #27176 - alexcrichton:fix-stock-llvm, r=brson
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:

* LLVM changes its IR syntax from time to time, so it's very difficult to
  have these files build across many LLVM versions simultaneously. We'll likely
  want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
  itself, so it makes sense to fold it into a location which can do more
  platform-specific checks for various implementation details (such as MSVC 32
  vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
  end up becoming very useful if we move towards building the standard library
  with Cargo.

In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 22, 2015

Contributor

⌛️ Testing commit c35b2bd with merge 3475c5b...

Contributor

bors commented Jul 22, 2015

⌛️ Testing commit c35b2bd with merge 3475c5b...

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 22, 2015

Contributor

💔 Test failed - auto-win-gnu-64-nopt-t

Contributor

bors commented Jul 22, 2015

💔 Test failed - auto-win-gnu-64-nopt-t

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 22, 2015

Member

@bors: retry

On Tue, Jul 21, 2015 at 9:19 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-gnu-64-nopt-t/builds/766


Reply to this email directly or view it on GitHub
#27176 (comment).

Member

alexcrichton commented Jul 22, 2015

@bors: retry

On Tue, Jul 21, 2015 at 9:19 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-gnu-64-nopt-t/builds/766


Reply to this email directly or view it on GitHub
#27176 (comment).

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 22, 2015

Contributor

⌛️ Testing commit c35b2bd with merge 25281b1...

Contributor

bors commented Jul 22, 2015

⌛️ Testing commit c35b2bd with merge 25281b1...

bors added a commit that referenced this pull request Jul 22, 2015

Auto merge of #27176 - alexcrichton:fix-stock-llvm, r=brson
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:

* LLVM changes its IR syntax from time to time, so it's very difficult to
  have these files build across many LLVM versions simultaneously. We'll likely
  want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
  itself, so it makes sense to fold it into a location which can do more
  platform-specific checks for various implementation details (such as MSVC 32
  vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
  end up becoming very useful if we move towards building the standard library
  with Cargo.

In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.

@bors bors merged commit c35b2bd into rust-lang:master Jul 22, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@alexcrichton alexcrichton deleted the alexcrichton:fix-stock-llvm branch Jul 22, 2015

@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Jul 22, 2015

Contributor

:(
Couldn't we've ran .ll files through cpp (like is done with regular asm) for the same effect?

Contributor

vadimcn commented Jul 22, 2015

:(
Couldn't we've ran .ll files through cpp (like is done with regular asm) for the same effect?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 22, 2015

Member

In theory, yes, but that still requires the standard library to have llc available to compile itself, which we need to move away from if we want to build std with Cargo at some point. It also would have been interesting trying to detect the llc version, pass the right variables to the preprocessor, and then piping all that back into llc to create an object.

Member

alexcrichton commented Jul 22, 2015

In theory, yes, but that still requires the standard library to have llc available to compile itself, which we need to move away from if we want to build std with Cargo at some point. It also would have been interesting trying to detect the llc version, pass the right variables to the preprocessor, and then piping all that back into llc to create an object.

@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Jul 22, 2015

Contributor

In theory, yes, but that still requires the standard library to have llc available to compile itself

I am not sure I understand this point. Didn't rust_trylive in rustrt_native library? Which is effectively a part of the compiler, which already requires LLVM to be around.
How it it different from all other runtime fns in rustrt_native and compiler-rt?

My concern with the new way is that:

  • Emitting IR via LLVM API takes a lot more work and is way less readable because of all the noise added by API usage.
  • One cannot override rust_try for a custom target, (like you we able to do for *-pc-windows-msvc) without changing the compiler.
Contributor

vadimcn commented Jul 22, 2015

In theory, yes, but that still requires the standard library to have llc available to compile itself

I am not sure I understand this point. Didn't rust_trylive in rustrt_native library? Which is effectively a part of the compiler, which already requires LLVM to be around.
How it it different from all other runtime fns in rustrt_native and compiler-rt?

My concern with the new way is that:

  • Emitting IR via LLVM API takes a lot more work and is way less readable because of all the noise added by API usage.
  • One cannot override rust_try for a custom target, (like you we able to do for *-pc-windows-msvc) without changing the compiler.
@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Jul 22, 2015

Contributor

(sorry for jumping in late - I was not aware of this change until bors told me that my PR collided with this one)

Contributor

vadimcn commented Jul 22, 2015

(sorry for jumping in late - I was not aware of this change until bors told me that my PR collided with this one)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 22, 2015

Member

I am not sure I understand this point. Didn't rust_trylive in rustrt_native library? Which is effectively a part of the compiler, which already requires LLVM to be around.
How it it different from all other runtime fns in rustrt_native and compiler-rt?

Ah by this I just mean that the tool llc is no longer needed to build the standard library.

The other shims and such in rustrt_native can be built with a normal C compiler and I believe that all the shims in compiler-rt can also be built with a normal C compiler. If you're in theory cross compiling the standard library to a new architecture it's much more likely you've got the right C compiler installed vs llc.

Emitting IR via LLVM API takes a lot more work and is way less readable because of all the noise added by API usage.

I don't disagree with this!

One cannot override rust_try for a custom target, (like you we able to do for *-pc-windows-msvc) without changing the compiler.

I'm not quite sure I follow this. Is this basically saying that it's easier to edit IR than it is to edit the compiler?

sorry for jumping in late - I was not aware of this change until bors told me that my PR collided with this one

No worries!

Member

alexcrichton commented Jul 22, 2015

I am not sure I understand this point. Didn't rust_trylive in rustrt_native library? Which is effectively a part of the compiler, which already requires LLVM to be around.
How it it different from all other runtime fns in rustrt_native and compiler-rt?

Ah by this I just mean that the tool llc is no longer needed to build the standard library.

The other shims and such in rustrt_native can be built with a normal C compiler and I believe that all the shims in compiler-rt can also be built with a normal C compiler. If you're in theory cross compiling the standard library to a new architecture it's much more likely you've got the right C compiler installed vs llc.

Emitting IR via LLVM API takes a lot more work and is way less readable because of all the noise added by API usage.

I don't disagree with this!

One cannot override rust_try for a custom target, (like you we able to do for *-pc-windows-msvc) without changing the compiler.

I'm not quite sure I follow this. Is this basically saying that it's easier to edit IR than it is to edit the compiler?

sorry for jumping in late - I was not aware of this change until bors told me that my PR collided with this one

No worries!

@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Jul 23, 2015

Contributor

I'm not quite sure I follow this. Is this basically saying that it's easier to edit IR than it is to edit the compiler?

I meant that as a library function in rustrt_native, it could have been overridden. Not so much with it as compiler intrinsic.
In principle, rust_try could have been implemented in C++, assembly, or even in C, if the compiler supports suitable extensions. It's just hard to do so portably.

Contributor

vadimcn commented Jul 23, 2015

I'm not quite sure I follow this. Is this basically saying that it's easier to edit IR than it is to edit the compiler?

I meant that as a library function in rustrt_native, it could have been overridden. Not so much with it as compiler intrinsic.
In principle, rust_try could have been implemented in C++, assembly, or even in C, if the compiler supports suitable extensions. It's just hard to do so portably.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 23, 2015

Member

How do you override something in a native library? You mean avoiding #[cfg(stage0)]?

The ABI of unwinding is very closely tied to the compiler itself, so even though it could be implemented in various locations it kinda makes sense to me to implement this as an intrinsic so the compiler has complete control over all ABI possibilities.

Member

alexcrichton commented Jul 23, 2015

How do you override something in a native library? You mean avoiding #[cfg(stage0)]?

The ABI of unwinding is very closely tied to the compiler itself, so even though it could be implemented in various locations it kinda makes sense to me to implement this as an intrinsic so the compiler has complete control over all ABI possibilities.

@vadimcn

This comment has been minimized.

Show comment
Hide comment
@vadimcn

vadimcn Jul 23, 2015

Contributor

How do you override something in a native library?

I meant that when building rustrt_native for a new target, you could write a custom rust_try.

Contributor

vadimcn commented Jul 23, 2015

How do you override something in a native library?

I meant that when building rustrt_native for a new target, you could write a custom rust_try.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 23, 2015

Member

That's true, but do you know if that's done often? From what I've seen the rust_try.ll file basically never changes.

Member

alexcrichton commented Jul 23, 2015

That's true, but do you know if that's done often? From what I've seen the rust_try.ll file basically never changes.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jul 24, 2015

Member

Was it known that this would break unwinding entirely on -Z no-landing-pads builds?
This means check-stage1-cfail fails miserably, it need at least the rust_try landing pad to run.

Individual stage1 rustc invocations will abort with fatal runtime error: Could not unwind stack, error = 5 if any errors are found.
And then the compiletest driver will panic! during handling of the unexpected SIGILL in rustc, triggering another fatal runtime error: Could not unwind stack, error = 5 abort, hiding the original rustc one.

Member

eddyb commented Jul 24, 2015

Was it known that this would break unwinding entirely on -Z no-landing-pads builds?
This means check-stage1-cfail fails miserably, it need at least the rust_try landing pad to run.

Individual stage1 rustc invocations will abort with fatal runtime error: Could not unwind stack, error = 5 if any errors are found.
And then the compiletest driver will panic! during handling of the unexpected SIGILL in rustc, triggering another fatal runtime error: Could not unwind stack, error = 5 abort, hiding the original rustc one.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jul 24, 2015

Member

Actually, scratch that, it's because the snapshot compiler doesn't have the try intrinsic so this PR uses a noop, breaking unwinding for the stage1 compiler and tests until the next snapshot.

Member

eddyb commented Jul 24, 2015

Actually, scratch that, it's because the snapshot compiler doesn't have the try intrinsic so this PR uses a noop, breaking unwinding for the stage1 compiler and tests until the next snapshot.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 24, 2015

Member

@eddyb yes this was known.

Member

alexcrichton commented Jul 24, 2015

@eddyb yes this was known.

geofft added a commit to geofft/std-with-cargo that referenced this pull request Aug 31, 2015

Update cargo-ify.patch for current Rust
On the functionality side, morestack is gone (rust-lang/rust#27338), and
rustrt_native is gone (rust-lang/rust#27176).

On the implementation side, connect has been renamed to join
(rust-lang/rust#26957).

geofft added a commit to geofft/std-with-cargo that referenced this pull request Aug 31, 2015

Remove LLVM requirement from README.md and .travis.yml
rust-lang/rust#27176 "removes LLVM as a build-time dependency of the
standard library. This may end up becoming very useful if we move
towards building the standard library with Cargo."

@arielb1 arielb1 referenced this pull request Sep 15, 2015

Merged

1.3 relnotes #28408

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment