From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1643) id 0C42E3858408; Thu, 1 Dec 2022 08:12:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C42E3858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669882352; bh=B2/0JFX7r88fyqIml9ldn36c10dKwEAjvazDrpnM520=; h=From:To:Subject:Date:From; b=HlbiQsLSYqctuoUKvTsdi0OgaWdYH8Ew/HZRxqro+gEtuM655tWBXJoEi2OYHmK2n cDfatO/09Om4lOq9ywfKzcyHEOcf6exkfB9WFLdKbuMhHuqH/aCr7DW++SSDQvforN DkuAE2TRcCd4t/xZdSWAySZG7fq/AZli/dC632bw= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Thomas Schwinge To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/rust/master] Merge #1630 X-Act-Checkin: gcc X-Git-Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com> X-Git-Refname: refs/heads/devel/rust/master X-Git-Oldrev: 71b8beb150d96548a2ebfb8ef964d14225e300f0 X-Git-Newrev: 738df996e0b5ce53b8681cdc34e64cf0f2b37020 Message-Id: <20221201081232.0C42E3858408@sourceware.org> Date: Thu, 1 Dec 2022 08:12:32 +0000 (GMT) List-Id: 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(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(src: *const i32, locality: i32) { __builtin_prefetch(src, 0, locality) } ``` we'd swap the call to `prefetch_read_data::(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 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(-)