public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt)
Date: Wed, 06 Sep 2023 15:57:35 +0000	[thread overview]
Message-ID: <bug-102989-4-HHE9mT0TlU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102989-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #97 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a9d6c7fbeb374365058ffe2b9815d2b4b7193d38

commit r14-3746-ga9d6c7fbeb374365058ffe2b9815d2b4b7193d38
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Sep 6 17:27:41 2023 +0200

    _BitInt lowering support [PR102989]

    The following patch adds a new bitintlower lowering pass which lowers most
    operations on medium _BitInt into operations on corresponding integer
types,
    large _BitInt into straight line code operating on 2 or more limbs and
    finally huge _BitInt into a loop plus optional straight line code.

    As the only supported architecture is little-endian, the lowering only
    supports little-endian for now, because it would be impossible to test it
    all for big-endian.  Rest is written with any endian support in mind, but
    of course only little-endian has been actually tested.
    I hope it is ok to add big-endian support to the lowering pass
incrementally
    later when first big-endian target shows with the backend support.
    There are 2 possibilities of adding such support, one would be minimal one,
    just tweak limb_access function and perhaps one or two other spots and
    transform there the indexes from little endian (index 0 is least
significant)
    to big endian for just the memory access.  Advantage is I think
maintainance
    costs, disadvantage is that the loops will still iterate from 0 to some
number
    of limbs and we'd rely on IVOPTs or something similar changing it later if
    needed.  Or we could make those indexes endian related everywhere, though
    I'm afraid that would be several hundreds of changes.

    For switches indexed by large/huge _BitInt the patch invokes what the
switch
    lowering pass does (but only on those specific switches, not all of them);
    the switch lowering breaks the switches into clusters and none of the
clusters
    can have a range which doesn't fit into 64-bit UWHI, everything else will
be
    turned into a tree of comparisons.  For clusters normally emitted as
smaller
    switches, because we already have a guarantee that the low .. high range is
    at most 64 bits, the patch forces subtraction of the low and turns it into
    a 64-bit switch.  This is done before the actual pass starts.
    Similarly, we cancel lowering of certain constructs like ABS_EXPR,
ABSU_EXPR,
    MIN_EXPR, MAX_EXPR and COND_EXPR and turn those back to simpler comparisons
    etc., so that fewer operations need to be lowered later.

    2023-09-06  Jakub Jelinek  <jakub@redhat.com>

            PR c/102989
            * Makefile.in (OBJS): Add gimple-lower-bitint.o.
            * passes.def: Add pass_lower_bitint after pass_lower_complex and
            pass_lower_bitint_O0 after pass_lower_complex_O0.
            * tree-pass.h (PROP_gimple_lbitint): Define.
            (make_pass_lower_bitint_O0, make_pass_lower_bitint): Declare.
            * gimple-lower-bitint.h: New file.
            * tree-ssa-live.h (struct _var_map): Add bitint member.
            (init_var_map): Adjust declaration.
            (region_contains_p): Handle map->bitint like map->outofssa_p.
            * tree-ssa-live.cc (init_var_map): Add BITINT argument, initialize
            map->bitint and set map->outofssa_p to false if it is non-NULL.
            * tree-ssa-coalesce.cc: Include gimple-lower-bitint.h.
            (build_ssa_conflict_graph): Call build_bitint_stmt_ssa_conflicts if
            map->bitint.
            (create_coalesce_list_for_region): For map->bitint ignore SSA_NAMEs
            not in that bitmap, and allow res without default def.
            (compute_optimized_partition_bases): In map->bitint mode try hard
to
            coalesce any SSA_NAMEs with the same size.
            (coalesce_bitint): New function.
            (coalesce_ssa_name): In map->bitint mode, or map->bitmap into
            used_in_copies and call coalesce_bitint.
            * gimple-lower-bitint.cc: New file.

  parent reply	other threads:[~2023-09-06 15:57 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 17:41 [Bug c/102989] New: Add Clang's _ExtInt(N) colomar.6.4.3 at gmail dot com
2021-10-28 17:54 ` [Bug c/102989] " colomar.6.4.3 at gmail dot com
2021-10-28 17:57 ` colomar.6.4.3 at gmail dot com
2021-10-28 17:57 ` colomar.6.4.3 at gmail dot com
2021-10-28 18:01 ` jakub at gcc dot gnu.org
2021-10-28 18:11 ` colomar.6.4.3 at gmail dot com
2021-10-28 21:41 ` joseph at codesourcery dot com
2021-10-28 21:47 ` [Bug c/102989] Implement C2x's n2763 (_BitInt) pinskia at gcc dot gnu.org
2021-10-28 21:49 ` pinskia at gcc dot gnu.org
2021-11-11 19:42 ` pinskia at gcc dot gnu.org
2021-11-11 19:58 ` colomar.6.4.3 at gmail dot com
2021-11-11 21:27 ` joseph at codesourcery dot com
2022-10-25 12:14 ` jakub at gcc dot gnu.org
2022-10-25 15:25 ` hjl.tools at gmail dot com
2022-10-25 20:32 ` joseph at codesourcery dot com
2022-10-25 20:42 ` hjl.tools at gmail dot com
2022-10-25 20:45 ` jakub at gcc dot gnu.org
2022-10-25 21:05 ` segher at gcc dot gnu.org
2022-10-25 21:05 ` hjl.tools at gmail dot com
2022-10-25 21:09 ` pinskia at gcc dot gnu.org
2022-10-25 21:10 ` jakub at gcc dot gnu.org
2022-10-25 21:30 ` segher at gcc dot gnu.org
2022-10-25 21:50 ` segher at gcc dot gnu.org
2022-10-26  6:29 ` uweigand at gcc dot gnu.org
2022-10-26  6:50 ` jakub at gcc dot gnu.org
2022-10-26  8:35 ` redi at gcc dot gnu.org
2022-10-26 17:29 ` joseph at codesourcery dot com
2022-10-28  9:47 ` rguenth at gcc dot gnu.org
2022-10-28 10:32 ` jakub at gcc dot gnu.org
2022-10-28 10:51 ` rguenther at suse dot de
2022-10-28 11:02 ` colomar.6.4.3 at gmail dot com
2022-10-28 17:27 ` pinskia at gcc dot gnu.org
2022-10-28 20:31 ` joseph at codesourcery dot com
2022-10-28 20:39 ` joseph at codesourcery dot com
2023-04-09 19:59 ` leni536 at gmail dot com
2023-04-12 22:17 ` george at bott dot gg
2023-05-11 18:00 ` jakub at gcc dot gnu.org
2023-05-11 18:21 ` jakub at gcc dot gnu.org
2023-05-11 22:10 ` joseph at codesourcery dot com
2023-05-12  7:46 ` jakub at gcc dot gnu.org
2023-05-12  8:41 ` rguenth at gcc dot gnu.org
2023-05-16 16:20 ` jakub at gcc dot gnu.org
2023-05-17  7:22 ` rguenth at gcc dot gnu.org
2023-05-23 12:04 ` jakub at gcc dot gnu.org
2023-05-24 11:48 ` jakub at gcc dot gnu.org
2023-05-24 12:46 ` rguenther at suse dot de
2023-05-24 13:16 ` jakub at gcc dot gnu.org
2023-05-24 13:29 ` rguenther at suse dot de
2023-05-24 14:18 ` jakub at gcc dot gnu.org
2023-05-24 14:57 ` rguenther at suse dot de
2023-05-24 15:31 ` jakub at gcc dot gnu.org
2023-05-26 16:13 ` jakub at gcc dot gnu.org
2023-05-26 16:16 ` jakub at gcc dot gnu.org
2023-05-26 17:11 ` jakub at gcc dot gnu.org
2023-06-02 10:39 ` jakub at gcc dot gnu.org
2023-06-02 10:43 ` rguenther at suse dot de
2023-06-02 10:53 ` jakub at gcc dot gnu.org
2023-06-02 17:06 ` jakub at gcc dot gnu.org
2023-06-05  7:14 ` rguenth at gcc dot gnu.org
2023-06-05  7:34 ` jakub at gcc dot gnu.org
2023-06-05  7:43 ` rguenth at gcc dot gnu.org
2023-06-05  7:58 ` jakub at gcc dot gnu.org
2023-06-05  8:21 ` rguenther at suse dot de
2023-06-05  8:33 ` jakub at gcc dot gnu.org
2023-06-06  7:13 ` rguenth at gcc dot gnu.org
2023-06-15 11:28 ` jakub at gcc dot gnu.org
2023-06-15 18:02 ` jakub at gcc dot gnu.org
2023-06-19 17:40 ` jakub at gcc dot gnu.org
2023-06-20 20:04 ` jakub at gcc dot gnu.org
2023-06-22 19:47 ` jakub at gcc dot gnu.org
2023-06-23 17:03 ` jakub at gcc dot gnu.org
2023-06-26 18:48 ` jakub at gcc dot gnu.org
2023-06-28 17:21 ` jakub at gcc dot gnu.org
2023-06-29 17:01 ` jakub at gcc dot gnu.org
2023-06-30 19:22 ` jakub at gcc dot gnu.org
2023-07-05 17:23 ` jakub at gcc dot gnu.org
2023-07-07 14:26 ` jakub at gcc dot gnu.org
2023-07-07 17:59 ` jakub at gcc dot gnu.org
2023-07-11 11:20 ` jakub at gcc dot gnu.org
2023-07-12 16:28 ` jakub at gcc dot gnu.org
2023-07-13 18:03 ` jakub at gcc dot gnu.org
2023-07-14 11:18 ` jakub at gcc dot gnu.org
2023-07-14 11:18 ` jakub at gcc dot gnu.org
2023-07-14 17:19 ` jakub at gcc dot gnu.org
2023-07-17 10:21 ` jakub at gcc dot gnu.org
2023-07-17 18:06 ` jakub at gcc dot gnu.org
2023-07-18 11:07 ` jakub at gcc dot gnu.org
2023-07-18 15:45 ` jakub at gcc dot gnu.org
2023-07-20 15:51 ` jakub at gcc dot gnu.org
2023-07-21 17:10 ` jakub at gcc dot gnu.org
2023-07-25 14:40 ` jakub at gcc dot gnu.org
2023-07-26 13:04 ` jakub at gcc dot gnu.org
2023-07-26 17:41 ` jakub at gcc dot gnu.org
2023-07-27 15:18 ` jakub at gcc dot gnu.org
2023-08-10  7:22 ` cvs-commit at gcc dot gnu.org
2023-08-10  7:23 ` cvs-commit at gcc dot gnu.org
2023-08-10 15:30 ` cvs-commit at gcc dot gnu.org
2023-08-14 21:55 ` tmgross at umich dot edu
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org [this message]
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:57 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-06 15:58 ` cvs-commit at gcc dot gnu.org
2023-09-07  9:21 ` cvs-commit at gcc dot gnu.org
2023-10-12 14:07 ` cvs-commit at gcc dot gnu.org
2023-10-14  7:38 ` cvs-commit at gcc dot gnu.org
2023-10-14 22:38 ` gaius at gcc dot gnu.org
2023-11-01  8:17 ` gaius at gcc dot gnu.org
2023-11-01  9:06 ` cvs-commit at gcc dot gnu.org

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=bug-102989-4-HHE9mT0TlU@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).