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 nowrap_{add|sub|mul|neg} intrinsics #52205

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
7 participants
@scottmcm
Copy link
Member

scottmcm commented Jul 10, 2018

LLVM cannot deduce nsw/nuw for things like Range::next today, so add these so that my next PR can use them to improve what Range tells LLVM.

(This adds the ones that rustc_codegen_llvm::builder::Builder and rustc_llvm::ffi currently support, which is why it has nowrap_neg but not nowrap_shl.)

tag guess: T-compiler

Add nowrap_{add|sub|mul|neg} intrinsics
LLVM cannot deduce nsw/nuw for things like Range::next today, so add these so that my next PR can use them to improve what Range tells LLVM.
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jul 10, 2018

r? @varkor

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

#[no_mangle]
pub unsafe fn nowrap_neg_unsigned(a: u32) -> u32 {
// CHECK: ret i32 0
nowrap_neg(a)

This comment has been minimized.

@scottmcm

scottmcm Jul 10, 2018

Author Member

Yes, this one is useless, since a non-overflowing negation of an unsigned type is always zero, but it was easier to support than to not support.

@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Jul 10, 2018

@bors r+

I see no reason not to do this, and if it ends up not helping we can always remove them

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 10, 2018

📌 Commit 9135ec5 has been approved by oli-obk

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented Jul 10, 2018

@bors r-

There’s no necessity to land intrinsics before a PR with an actual use case can be made (such as e.g. Range optimisations).

Please implement actual changes against Range and provide benchmarks before landing these intrinsics. All you’ll need are #[cfg(stage0)] and #[cfg(not(stage0))].

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented Jul 10, 2018

Also,

we can always remove them

is a very slippery slope, simply because it is way easier to forget and not remove something that ended up not being used (or not useful for some immediate use case). It is way easier to land everything together or not land stuff at all :)

@scottmcm

This comment has been minimized.

Copy link
Member Author

scottmcm commented Jul 10, 2018

Closing while I do that.

(Aside: cool to see that bors knows that an r- means the author probably needs to do something)

@gnzlbg

This comment has been minimized.

Copy link
Contributor

gnzlbg commented Aug 2, 2018

Here is an use case for these intrinsics: rust-lang/rfcs#2508

Basically, there is no easy way to generate LLVM-IR with nsw nuw flags via rustc today. This makes it very hard to even evaluate whether such operations should be exposed by higher-level APIs, or whether these flags have an impact at all on the generated code.

So I'd argue that these intrinsics are at least useful for hacking on rustc/LLVM, debugging performance issues, etc.

Also, I'd like to be able to play with intrinsics that also add both, the nsw and nuw flags, as well. That is, for add:

  • add nuw
  • add nsw
  • add nuw nsw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.