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

trans: Move rust_try into the compiler #27176

Merged
merged 1 commit into from
Jul 22, 2015

Conversation

alexcrichton
Copy link
Member

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
Copy link
Collaborator

r? @pcwalton

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

@alexcrichton
Copy link
Member Author

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
}

// 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
Copy link
Contributor

Choose a reason for hiding this comment

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

"ony" -> "only"

@alexcrichton alexcrichton force-pushed the fix-stock-llvm branch 2 times, most recently from 51016bd to 6046fb7 Compare July 21, 2015 07:47
@brson
Copy link
Contributor

brson commented Jul 21, 2015

@bors r+

@bors
Copy link
Contributor

bors commented Jul 21, 2015

📌 Commit 6046fb7 has been approved by brson

@brson
Copy link
Contributor

brson commented Jul 21, 2015

Awesome patch.

@alexcrichton alexcrichton force-pushed the fix-stock-llvm branch 4 times, most recently from 825860c to 970a3ca Compare July 21, 2015 22:31
@alexcrichton
Copy link
Member Author

@bors: r=brson

@bors
Copy link
Contributor

bors commented Jul 21, 2015

📌 Commit 970a3ca has been approved by brson

false);

// Define the "inner try" shim
let rust_try_inner = declare::declare_internal_rust_fn(ccx,
Copy link
Member

Choose a reason for hiding this comment

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

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

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
Copy link
Member Author

@bors: r=brson c35b2bd

@bors
Copy link
Contributor

bors commented Jul 22, 2015

⌛ Testing commit c35b2bd with merge 3475c5b...

@bors
Copy link
Contributor

bors commented Jul 22, 2015

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

@alexcrichton
Copy link
Member Author

@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
Copy link
Contributor

bors commented Jul 22, 2015

⌛ Testing commit c35b2bd with merge 25281b1...

bors added a commit that referenced this pull request Jul 22, 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.
@vadimcn
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
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
Copy link
Member Author

@eddyb yes this was known.

geofft added a commit to geofft/std-with-cargo that referenced this pull request Aug 31, 2015
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
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 mentioned this pull request Sep 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants