public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc/devel/rust/master] Merge #1630
Date: Thu,  1 Dec 2022 08:12:32 +0000 (GMT)	[thread overview]
Message-ID: <20221201081232.0C42E3858408@sourceware.org> (raw)

https://gcc.gnu.org/g:738df996e0b5ce53b8681cdc34e64cf0f2b37020

commit 738df996e0b5ce53b8681cdc34e64cf0f2b37020
Merge: 71b8beb150d fc59d137491
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Wed Nov 30 09:46:51 2022 +0000

    Merge #1630
    
    1630: Cleanup builtin handling r=CohenArthur a=CohenArthur
    
    This PR adds proper GCC-like handling of builtins, which allows us to not re-define all the builtins we use and fight with declaring the types each time.
    
    This is also safer and works better. Sadly, this has unearthed some problems in our handling of builtins, specifically the ones I've added recently (atomic ones and data prefetching). These are the two issues that remain for this PR to be in a nice state which does not cause regressions:
    
    1. `atomic_{store, load}` (and maybe cmp_xchg) do not work on signed integers. I'm currenty working around this by simply using `u32`s instead of `i32`s for the tests, but that's not a valid solution. These intrinsics need to work on all integer types and I will thus need to add some conversions from `i*` to `u*` before calling the intrinsics. The upside is that with these cleanups we should now be able to handle `*size` types easily and cleanly for those intrinsics
    2. `__builtin_prefetch()` requires the `locality` argument (third argument) to be a const value. While LLVM will let you build the function and maybe error out later down the line, GCC does not let you pass non compile time known values as locality arguments. Because we are trying to build the following intrinsic:
    
    ```rust
    fn prefetch_read_data<T>(src: *const T, locality: i32) {
        __builtin_prefetch(src, 1, locality);
    }
    ```
    
    we cannot know that the `locality` arg is a compile-time constant. There are two ways to go around this problem:
    
    a. Try to constant fold the `locality` argument. If this works, it's a compile time constant and we can keep going
    b. Somehow map a generic intrinsic directly to a GCC one and inserting a new argument. So instead of generating something like
    
    ```rust
    fn prefetch_read_data<i32>(src: *const i32, locality: i32) {
        __builtin_prefetch(src, 0, locality)
    }
    ```
    
    we'd swap the call to `prefetch_read_data::<i32>(src, locality)` with `__builtin_prefetch(src, 0, locality)` and enforce `locality` being a compile time constant.
    
    Edited because dynamically dispatching a *compiler hint* does not make any sense at all.
    
    Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>

Diff:

 gcc/rust/backend/rust-builtins.cc                  | 350 ++++++++++++++-------
 gcc/rust/backend/rust-builtins.h                   | 118 ++++++-
 gcc/rust/backend/rust-compile-intrinsic.cc         |  41 ++-
 gcc/rust/rust-gcc.cc                               |   8 +-
 gcc/testsuite/rust/compile/torture/intrinsics-4.rs |   2 +-
 gcc/testsuite/rust/execute/torture/atomic_load.rs  |   4 +-
 gcc/testsuite/rust/execute/torture/atomic_store.rs |   4 +-
 7 files changed, 389 insertions(+), 138 deletions(-)

                 reply	other threads:[~2022-12-01  8:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221201081232.0C42E3858408@sourceware.org \
    --to=tschwinge@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).