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

add an opt-in cargo feature to build intrinsics from compiler-rt source #74

Merged
merged 5 commits into from
Sep 30, 2016

Conversation

japaric
Copy link
Member

@japaric japaric commented Sep 26, 2016

closes #63
cc #66

This uses the build.rs version from rust-lang/rust#36512 minus the dependency on llvm-target being in rustc --print cfg

cc @alexcrichton I forgot to ask before but how do you feel about using the rustc-cfg crate, which parses the output of rustc --print cfg and exposes the target specification as a Rust struct, in the build.rs? Its functionality overlaps with what you proposed in rust-lang/rfcs#1721 i.e. CARGO_CFG_TARGET_OS, etc.

TODO stop compiling the C version of the intrinsics that we have already ported to Rust.

@japaric
Copy link
Member Author

japaric commented Sep 26, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit 310aaa9 with merge 310aaa9...

@homunkulus
Copy link
Contributor

💔 Test failed - status-travis

@alexcrichton
Copy link
Member

@japaric I'd personally prefer to keep the dependencies of the rust-lang/rust repo as slim as possible, and in that sense calling rustc --print cfg manually in theory shouldn't be too hard (including parsing). Otherwise using it to inform codegen seems good to me!

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

I'd personally prefer to keep the dependencies of the rust-lang/rust repo as slim as possible

does that include dev dependencies? This repo uses quickcheck for its tests.

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

Also, rustc-cfg has zero dependencies 😉.

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit 82bf52c with merge 82bf52c...

@homunkulus
Copy link
Contributor

💔 Test failed - status-travis

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

@alexcrichton having that intrinsics.rs test in this repository has helped me a lot in debugging issues with missing/undefined symbols. Thanks to it I just learned that the thumbv6m-none-eabi target doesn't support some floating point operations because the related compiler-rt intrinsics, which are written in assembly, can't be "compiled" for that target. (cf #75)

I'm actually wondering if it's actually necessary to also run the intrinsics.rs test on the rust-lang/rust repo. Seems like all intrinsics related changes would have to first go through this repository and the CI + intrinsics.rs in this repo should catch any problem as long as we are testing all tier 1 targets (I think I'm only missing android atm) and the intrinsics.rs file covers all the relevant operations (right now, it covers ~70 intrinsics).

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit ee05eb4 with merge ee05eb4...

@homunkulus
Copy link
Contributor

💔 Test failed - status-travis

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

@homunkulus try

OK. This should be ready to go now. Who wants to review? @Amanieu @mattico

The build.rs addition is pretty much a copy paste of the one from rust-lang/rust#36512 with additional changes to support the thumb* targets. I should have done that part in two commits so the additional changes were more obvious, sorry; but all the additions should have a "thumb" string near to it :-).

@homunkulus
Copy link
Contributor

⌛ Trying commit 7d49d99 with merge 7d49d99...

@mattico
Copy link
Contributor

mattico commented Sep 27, 2016

I'll take a look.

@homunkulus
Copy link
Contributor

💔 Test failed - status-appveyor

@mattico
Copy link
Contributor

mattico commented Sep 27, 2016

Looks like we ran into the gist rate limit on the CI, should be pretty easy to fix.

@japaric
Copy link
Member Author

japaric commented Sep 27, 2016

Oh right, I have to update the AppVeyor CI to test these changes. I'll probably have to use ugh powershell so I'm going to leave that for a follow-up PR.

Copy link
Contributor

@mattico mattico left a comment

Choose a reason for hiding this comment

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

Just some thoughts about link args for the intrinsics link test. Everything else looks good to me.

$CARGO clean

# verify we haven't drop any intrinsic/symbol
$CARGO build --features c --target $TARGET --bin intrinsics
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to have RUSTFLAGS="-C link-args='-Wl,-nostartfiles -Wl,-nodefaultlibs'" so that it applies to all targets? I'm assuming that we don't need libc anywhere in there...

Copy link
Member Author

Choose a reason for hiding this comment

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

Only -nostartfiles is needed on Linux. I think that would work on Linux, but idk about OSX and Windows. I'm using the libc crate because, on each platform, it links to different libraries needed to produce an executable. Without it the executable may not link at all.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good 👍. In any case it doesn't make much of a difference.

"features": "+strict-align",
"llvm-target": "thumbv6m-none-eabi",
"max-atomic-width": 0,
"os": "none",
"pre-link-args": ["-nostartfiles"],
Copy link
Contributor

Choose a reason for hiding this comment

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

If so, we wouldn't need these anymore.

@japaric
Copy link
Member Author

japaric commented Sep 29, 2016

@homunkulus try

This should be ready to go.

@alexcrichton Mind taking a look at the changes in the testing infra? Also, are you OK with adding rust-cfg here or would you prefer to just use $TARGET and .contains()?

@japaric
Copy link
Member Author

japaric commented Sep 29, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit b5797dc with merge b5797dc...

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit 62258b5 with merge 62258b5...


fn main() {
if env::var("TARGET").unwrap().ends_with("gnueabihf") {
println!("cargo:rerun-if-changed=build.rs");
Copy link
Member

Choose a reason for hiding this comment

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

If this is compiling a bunch of C files then this'll probably also want to print a similar key for those files as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

gcc-rs doesn't generate those for me?

// NOTE Most of the ARM intrinsics are written in assembly. Tell gcc which arch we are going to
// target to make sure that the assembly implementations really work for the target. If the
// implementation is not valid for the arch, then gcc will error when compiling it.
if llvm_target[0].starts_with("thumb") {
Copy link
Member

Choose a reason for hiding this comment

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

Could this logic be added to gcc-rs? (it'll be needed for any C code, right?)

Copy link
Member Author

Choose a reason for hiding this comment

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

If it's fine to add logic for targets that are not built into the compiler then I can send a PR.

Copy link
Member

Choose a reason for hiding this comment

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

Ah yeah that's true, but it's looking like we'll add these soon so I wouldn't mind adding them.

thumb*)
PREFIX=arm-none-eabi-
;;
*-unknown-linux-gnu | *-apple-darwin)
Copy link
Member

Choose a reason for hiding this comment

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

this'll catch mips/mipsel/powerpc, right? (is that intended?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah no. I meant to only pick up x86-ish targets. I'll fix it.

@alexcrichton
Copy link
Member

Mind taking a look at the changes in the testing infra?

Sure!

Also, are you OK with adding rust-cfg here or would you prefer to just use $TARGET and .contains()?

I think we'll end up adding this no matter what, so seems good to me!

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

@alexcrichton I've addressed all your comments I think.

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

Minus the gcc-rs bit because that will take time to land and we can always remove the gcc flags for thumb* later on

xargo build --features c --target $1 --bin intrinsics
;;
*)
cargo build --features c --target $1 --bin intrinsics
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this build could also be tested as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

cargo test --features c would end testing the same thing I think. We'll just be testing less intrinsics on some targets. Also, this would require sprinkling more cfg over the test modules.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, carry on then!

// convention for its intrinsics that's different from other architectures; that's why some function
// have an additional comment: the function name is the ARM name for the intrinsic and the comment
// in the non-ARM name for the intrinsic.
#[cfg(feature = "c")]
Copy link
Member

Choose a reason for hiding this comment

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

Some of these are defined even when feature=c is disabled, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Want to test those in the cfg(not(feature = "c")) main?

Copy link
Member

Choose a reason for hiding this comment

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

In theory yeah, but it's fine to land this ahead of time.

@alexcrichton
Copy link
Member

Looking good to me!

The #[cfg(not(all(feature = "c", ..)))] declarations look like they may get a bit unwieldy though in terms of management, but perhaps that can just be dealt with as it happens.

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

The #[cfg(not(all(feature = "c", ..)))] declarations look like they may get a bit unwieldy though in terms of management,

Let's get rid of the C code fast so we can soon get rid of all these cfgs and the C feature as well!

@alexcrichton
Copy link
Member

Let's get rid of the C code fast so we can soon get rid of all these cfgs and the C feature as well!

Agreed!

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

@homunkulus r+

Alright, let's land this. Then I can try landing this in rust-lang/rust, which is probably going to be awful

@homunkulus
Copy link
Contributor

📌 Commit 61484ac has been approved by japaric

@homunkulus
Copy link
Contributor

⌛ Testing commit 61484ac with merge 61484ac...

@homunkulus
Copy link
Contributor

💔 Test failed - status-travis

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

Did https://static.rust-lang.org/rustup.sh break? All the language: rust builds are failing.

@alexcrichton
Copy link
Member

I think? But claimed to be fixed.

Maybe it's not though?

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

@homunkulus retry

@homunkulus
Copy link
Contributor

⌛ Testing commit 61484ac with merge 61484ac...

@japaric
Copy link
Member Author

japaric commented Sep 30, 2016

@homunkulus r+

@homunkulus
Copy link
Contributor

📌 Commit cab88e6 has been approved by japaric

@homunkulus
Copy link
Contributor

⌛ Testing commit cab88e6 with merge cab88e6...

@homunkulus
Copy link
Contributor

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

@homunkulus homunkulus merged commit cab88e6 into master Sep 30, 2016
@japaric japaric deleted the c branch September 30, 2016 20:44
tgross35 pushed a commit to tgross35/compiler-builtins that referenced this pull request Feb 23, 2025
74: Implement roundf r=japaric a=P1n3appl3

closes rust-lang#32 

Co-authored-by: Joseph Ryan <[email protected]>
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.

Build missing intrinsics from compiler-rt (C) source code
4 participants