Add new #[target_feature = "..."] attribute. #38079

BurntSushi · 2016-11-30T00:03:16Z

This commit adds a new attribute that instructs the compiler to emit
target specific code for a single function. For example, the following
function is permitted to use instructions that are part of SSE 4.2:

#[target_feature = "+sse4.2"]
fn foo() { ... }

In particular, use of this attribute does not require setting the
-C target-feature or -C target-cpu options on rustc.

This attribute does not have any protections built into it. For example,
nothing stops one from calling the above foo function on hosts without
SSE 4.2 support. Doing so may result in a SIGILL.

I've also expanded the x86 target feature whitelist.

rust-highfive · 2016-11-30T00:03:29Z

r? @pnkfelix

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

BurntSushi · 2016-11-30T00:03:33Z

r? @alexcrichton

BurntSushi · 2016-11-30T00:08:10Z

Here are some questions/comments/concerns:

There is no validation of the values in target_feature. They are passed directly to LLVM at codegen time. This means errors (if any) are reported at codegen time.
The only test here is a compile-fail test that checks that target_feature is gated. I wanted to write a codegen test, but I don't quite know how for this particular change.
Should it be unsafe to call a function decorated with the target_feature attribute? (A different phrasing: should application of target_feature be limited to unsafe functions?)

I don't know whether any of the above should be fixed before merging. Certainly, they should at least be fixed/addressed before stabilization.

BurntSushi · 2016-11-30T00:08:16Z

cc @eddyb

eddyb · 2016-11-30T00:33:53Z

cc @rust-lang/compiler

eddyb · 2016-11-30T00:41:27Z

src/librustc_trans/attributes.rs

@@ -60,11 +62,10 @@ pub fn set_frame_pointer_elimination(ccx: &CrateContext, llfn: ValueRef) {
    // FIXME: #11906: Omitting frame pointers breaks retrieving the value of a
    // parameter.
    if ccx.sess().must_not_eliminate_frame_pointers() {
+        let name = CString::new("no-frame-pointer-elim").unwrap();
+        let val = CString::new("true").unwrap();


I think you can still use CStr with null-terminated &str.

eddyb · 2016-11-30T00:43:36Z

src/librustc_trans/attributes.rs

    for attr in attrs {
-        if attr.check_name("cold") {
+        if attr.check_name("target_feature") {
+            let val = attr.value_str().map_or(String::new(), |s|s.to_string());


This shouldn't allocate. You can use let val = attr.value_str().map(|s| s.as_str()); ... val.map_or("", |s| &s[..]).split(",").

It turns out this doesn't work because s is an InternedString. I just took the hit with the extra case analysis instead.

eddyb · 2016-11-30T00:44:38Z

src/librustc_trans/attributes.rs

+            for feat in val.split(",") {
+                let feat = feat.trim().to_string();
+                if !feat.is_empty() && !feat.contains('\0') {
+                    target_features.push(feat);


You can move the .to_string() on this line, or push to a String instead of allocating for each one.

eddyb · 2016-11-30T00:44:44Z

src/librustc_trans/attributes.rs

@@ -88,4 +97,10 @@ pub fn from_fn_attrs(ccx: &CrateContext, attrs: &[ast::Attribute], llfn: ValueRe
            unwind(llfn, true);
        }
    }
+    if !target_features.is_empty() {
+        let name = CString::new("target-features").unwrap();


Same here, I'm pretty sure you could avoid the allocation.

Yeah, I just didn't really care about the allocation. I'll fix them. :-)

alexcrichton · 2016-11-30T01:05:31Z

The x86 whitelist has ramifications elsewhere for the stable name of these features. The intention is that we ourselves maintain a mapping of features to the actual LLVM names, so that way if LLVM changes a name we can just update our implementation but the name we present to Rust is always stable.

In that sense could we perhaps be more conservative with the update to the x86 whitelist? Perhaps only the features needed for SIMD progress for now?

BurntSushi · 2016-11-30T01:29:23Z

@alexcrichton Ah whoops! I will trim it back down to what it was, but I think we should add at least lzcnt, popcnt and sse4a. lzcnt and popcnt in particular were introduced with SSE4, but they were given their own CPUID bits. See: https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT

BurntSushi · 2016-11-30T01:31:24Z

(We will definitely want to add more from that list at time moves on. AVX512 has a particularly large presence, but I think we should punt on AVX512 for this initial push. It it absolutely gigantic.)

This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example, the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = "+sse4.2"] fn foo() { ... } In particular, use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example, nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt, popcnt and sse4a. Namely, lzcnt and popcnt have their own CPUID bits, but were introduced with SSE4.

sfackler · 2016-11-30T02:59:44Z

I think I'd agree that we should require target_feature functions to be unsafe.

EDIT: Hmm, maybe not - I don't think you'd see anything worse than a crash, and a crash isn't memory unsafe, right?

BurntSushi · 2016-11-30T03:04:32Z

To be more precise, I think the failure mode is that your program attempts to execute an instruction that the CPU doesn't recognize. Is this behavior actually defined to always crash your program?

eddyb · 2016-11-30T03:33:26Z

@BurntSushi If the kernel doesn't emulate it then you get a SIGILL on most UNIX systems (I would hope).
Paging @retep998 for windows behavior (I'd assume it's a SEH exception or something similar).

retep998 · 2016-11-30T04:16:29Z

If you attempt to execute an illegal instruction on Windows, a STATUS_ILLEGAL_INSTRUCTION exception is fired.

sanxiyn · 2016-11-30T05:02:29Z

Note that "target-features" function attribute is undocumented. So while LLVM is unstable, this attribute is extra unstable, even unstable by LLVM standard.

At least in 2015, a bug about "target-features" function attribute was closed as "LATER". See LLVM bug 22081. Hopefully this changed, but I haven't seen any announcement. Did anyone?

BurntSushi · 2016-11-30T12:30:54Z

@sanxiyn If it's good enough for Clang and LDC, is it good enough for Rust? (I note that gcc seems to support a similar---possibly identical---feature.)

As a side note, our current trajectory for SIMD stabilization hinges pretty critically on #[target_feature]. Without it, we're pretty much back to the drawing board. (One possibility would be to keep the attribute unstable and only use it in std, which would get us somewhere, but that seems unfortunate.)

I don't know what the proper channels are to inquire about something like this.

sanxiyn · 2016-11-30T13:31:15Z

I am simply pointing out two things. One, the attribute is unstable in LLVM. Of course, that doesn't mean it can't be stable in Rust. In principle, Rust is already using LLVM C++ API, which is also unstable.

Two, #[target_feature] and -C target-feature are not equivalent. They should be, but for various reasons they aren't at the moment. And as far as I know LLVM upstream is not very interested in fixing cases when they aren't equivalent.

alexcrichton · 2016-12-01T00:44:59Z

r+ from me on this. I'm fine on punting on requiring unsafe. This is an unstable feature for now and we'll spec it out more before stabilizing. In the time being it allows playing around with SIMD and exploring the possible design space there.

I'm also fine using something unstable in LLVM, especially in an unstable API. Presumably the clang feature of __attribute__ is "stable", so there will always be some way of doing this. If that changes over time in LLVM revisions then it's no different than anything else we use from LLVM, really.

@eddyb do all the trans pieces here look good to you?

eddyb · 2016-12-01T01:26:53Z

Yeah, it looks good to me.

alexcrichton · 2016-12-01T01:28:11Z

Ok

@bors: r+

bors · 2016-12-01T01:28:12Z

📌 Commit 80ef1db has been approved by alexcrichton

bors · 2016-12-03T17:36:20Z

⌛ Testing commit 80ef1db with merge 2cdbd5e...

Add new #[target_feature = "..."] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example, the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = "+sse4.2"] fn foo() { ... } In particular, use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example, nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. I've also expanded the x86 target feature whitelist.

bors · 2016-12-03T20:54:04Z

rust-highfive assigned pnkfelix Nov 30, 2016

rust-highfive assigned alexcrichton and unassigned pnkfelix Nov 30, 2016

eddyb reviewed Nov 30, 2016

View reviewed changes

BurntSushi force-pushed the attrtarget branch from e46652a to 80ef1db Compare November 30, 2016 01:33

bors merged commit 80ef1db into rust-lang:master Dec 3, 2016

bors mentioned this pull request Dec 3, 2016

i128 and u128 support #37900

Closed

2 tasks

BurntSushi deleted the attrtarget branch December 3, 2016 21:00

bors mentioned this pull request Dec 3, 2016

Cast suggestions #38099

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add new #[target_feature = "..."] attribute. #38079

Add new #[target_feature = "..."] attribute. #38079

BurntSushi commented Nov 30, 2016 •

edited

Loading

rust-highfive commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

eddyb commented Nov 30, 2016

eddyb Nov 30, 2016

eddyb Nov 30, 2016

BurntSushi Nov 30, 2016

eddyb Nov 30, 2016

eddyb Nov 30, 2016

BurntSushi Nov 30, 2016 •

edited

Loading

alexcrichton commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

sfackler commented Nov 30, 2016 •

edited

Loading

BurntSushi commented Nov 30, 2016

eddyb commented Nov 30, 2016

retep998 commented Nov 30, 2016 •

edited

Loading

sanxiyn commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

sanxiyn commented Nov 30, 2016

alexcrichton commented Dec 1, 2016

eddyb commented Dec 1, 2016

alexcrichton commented Dec 1, 2016

bors commented Dec 1, 2016

bors commented Dec 3, 2016

bors commented Dec 3, 2016

Add new #[target_feature = "..."] attribute. #38079

Add new #[target_feature = "..."] attribute. #38079

Conversation

BurntSushi commented Nov 30, 2016 • edited Loading

rust-highfive commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

eddyb commented Nov 30, 2016

eddyb Nov 30, 2016

Choose a reason for hiding this comment

eddyb Nov 30, 2016

Choose a reason for hiding this comment

BurntSushi Nov 30, 2016

Choose a reason for hiding this comment

eddyb Nov 30, 2016

Choose a reason for hiding this comment

eddyb Nov 30, 2016

Choose a reason for hiding this comment

BurntSushi Nov 30, 2016 • edited Loading

Choose a reason for hiding this comment

alexcrichton commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

sfackler commented Nov 30, 2016 • edited Loading

BurntSushi commented Nov 30, 2016

eddyb commented Nov 30, 2016

retep998 commented Nov 30, 2016 • edited Loading

sanxiyn commented Nov 30, 2016

BurntSushi commented Nov 30, 2016

sanxiyn commented Nov 30, 2016

alexcrichton commented Dec 1, 2016

eddyb commented Dec 1, 2016

alexcrichton commented Dec 1, 2016

bors commented Dec 1, 2016

bors commented Dec 3, 2016

bors commented Dec 3, 2016

BurntSushi commented Nov 30, 2016 •

edited

Loading

BurntSushi Nov 30, 2016 •

edited

Loading

sfackler commented Nov 30, 2016 •

edited

Loading

retep998 commented Nov 30, 2016 •

edited

Loading