aboutsummaryrefslogtreecommitdiff
path: root/gcc/target.h
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2023-12-15 12:40:51 +0100
committerJakub Jelinek <jakub@redhat.com>2023-12-15 12:40:51 +0100
commita98a39328643e092aa6f0d98586a9b7f92bfff91 (patch)
treefdc3185afabc87c3a5f3e01eefa94f38d3f1fcaf /gcc/target.h
parentf5745dc1426bdb1a53ebaf7af758b2250ccbff02 (diff)
downloadgcc-a98a39328643e092aa6f0d98586a9b7f92bfff91.zip
gcc-a98a39328643e092aa6f0d98586a9b7f92bfff91.tar.gz
gcc-a98a39328643e092aa6f0d98586a9b7f92bfff91.tar.bz2
bitint: Introduce abi_limb_mode
Given what I saw in the aarch64/arm psABIs for BITINT_TYPE, as I said earlier I'm afraid we need to differentiate between the limb mode/precision specified in the psABIs (what is used to decide how it is actually passed, aligned or what size it has) vs. what limb mode/precision should be used during bitint lowering and in the libgcc bitint APIs. While in the x86_64 psABI a limb is 64-bit, which is perfect for both, that is a wordsize which we can perform operations natively in, e.g. aarch64 wants 128-bit limbs for alignment/sizing purposes, but on the bitint lowering side I believe it would result in terribly bad code and on the libgcc side wouldn't work at all (because it relies there on longlong.h support). So, the following patch makes it possible for aarch64 to use TImode as abi_limb_mode for _BitInt(129) and larger, while using DImode as limb_mode. 2023-12-15 Jakub Jelinek <jakub@redhat.com> * target.h (struct bitint_info): Add abi_limb_mode member, adjust comment. * target.def (bitint_type_info): Mention abi_limb_mode instead of limb_mode. * varasm.cc (output_constant): Use abi_limb_mode rather than limb_mode. * stor-layout.cc (finish_bitfield_representative): Likewise. Assert that if precision is smaller or equal to abi_limb_mode precision or if info.big_endian is different from WORDS_BIG_ENDIAN, info.limb_mode must be the same as info.abi_limb_mode. (layout_type): Use abi_limb_mode rather than limb_mode. * gimple-fold.cc (clear_padding_bitint_needs_padding_p): Likewise. (clear_padding_type): Likewise. * config/i386/i386.cc (ix86_bitint_type_info): Also set info->abi_limb_mode. * doc/tm.texi: Regenerated.
Diffstat (limited to 'gcc/target.h')
-rw-r--r--gcc/target.h16
1 files changed, 12 insertions, 4 deletions
diff --git a/gcc/target.h b/gcc/target.h
index a055b25..53f03b3 100644
--- a/gcc/target.h
+++ b/gcc/target.h
@@ -69,15 +69,23 @@ union cumulative_args_t { void *p; };
#endif /* !CHECKING_P */
/* Target properties of _BitInt(N) type. _BitInt(N) is to be represented
- as series of limb_mode CEIL (N, GET_MODE_PRECISION (limb_mode)) limbs,
- ordered from least significant to most significant if !big_endian,
+ as series of abi_limb_mode CEIL (N, GET_MODE_PRECISION (abi_limb_mode))
+ limbs, ordered from least significant to most significant if !big_endian,
otherwise from most significant to least significant. If extended is
false, the bits above or equal to N are undefined when stored in a register
or memory, otherwise they are zero or sign extended depending on if
- it is unsigned _BitInt(N) or _BitInt(N) / signed _BitInt(N). */
+ it is unsigned _BitInt(N) or _BitInt(N) / signed _BitInt(N).
+ limb_mode is either the same as abi_limb_mode, or some narrower mode
+ in which _BitInt lowering should actually perform operations in and
+ what libgcc _BitInt helpers should use.
+ E.g. abi_limb_mode could be TImode which is something some processor
+ specific ABI would specify to use, but it would be desirable to handle
+ it as an array of DImode instead for efficiency.
+ Note, abi_limb_mode can be different from limb_mode only if big_endian
+ matches WORDS_BIG_ENDIAN. */
struct bitint_info {
- machine_mode limb_mode;
+ machine_mode abi_limb_mode, limb_mode;
bool big_endian;
bool extended;
};