[Bug target/112993] New: rs6000: Rework precision for 128bit float types and modes

[Bug target/112993] New: rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org]

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

            Bug ID: 112993
           Summary: rs6000: Rework precision for 128bit float types and
                    modes
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: build, ice-checking, ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linkw at gcc dot gnu.org
                CC: amacleod at redhat dot com, andy at gwentswordclub dot co.uk,
                    bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
                    meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
                    seurer at gcc dot gnu.org, tschwinge at gcc dot gnu.org
        Depends on: 112788
  Target Milestone: ---
              Host: powerpc64le-linux-gnu
            Target: powerpc64le-linux-gnu
             Build: powerpc64le-linux-gnu

+++ This bug was initially created as a clone of Bug #112788 +++

As PR112788 shows and the review comments from Andrew and Jakub at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640342.html, we should
get rid of the workaround for PR112788 from GCC 15+.

This PR is filed for tracking this, we would expect that the precision for
those types and modes are all 128 bit, also TFmode becomes one macro
conditionally defined as IFmode or KFmode.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
[Bug 112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after
r14-5972-gea19de921b01a6

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-12-13
     Ever confirmed|0                           |1
           Keywords|build, ice-checking,        |internal-improvement
                   |ice-on-valid-code           |
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 112788, which changed state.

Bug 112788 Summary: [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:3f6e6d4b408a26f69816f18d88dde4d983677488

commit r15-2083-g3f6e6d4b408a26f69816f18d88dde4d983677488
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:14:18 2024 -0500

    expr: Allow same precision modes conversion between {ibm_extended,
ieee_quad}_format

    With some historical reasons, rs6000 defines KFmode, TFmode
    and IFmode to have different mode precisions, but it causes
    some issues and needs some workarounds such as PR112993.
    So we are going to make all rs6000 128 bit scalar FP modes
    have 128 bit precision.  Be prepared for that, this patch
    is to make function convert_mode_scalar allow same precision
    FP modes conversion if their underlying formats are
    ibm_extended_format and ieee_quad_format respectively, just
    like the existing special treatment on arm_bfloat_half_format
    <-> ieee_half_format.  It also factors out all the relevant
    checks into a lambda function.  Besides, similar to ieee fp16
    -> bfloat conversion, it adopts trunc_optab rather than
    sext_optab for ibm128 to ieee128 conversion.

            PR target/112993

    gcc/ChangeLog:

            * expr.cc (convert_mode_scalar): Allow same precision conversion
            between scalar floating point modes if whose underlying format is
            ibm_extended_format or ieee_quad_format, and refactor assertion
            with new lambda function acceptable_same_precision_modes.  Use
            trunc_optab rather than sext_optab for ibm128 to ieee128
conversion.
            * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Use trunc_optab
rather
            than sext_optab for ibm128 to ieee128 conversion.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:33dca0a4c1c421625cedb2d6105ef1c05f6b774e

commit r15-2084-g33dca0a4c1c421625cedb2d6105ef1c05f6b774e
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:14:43 2024 -0500

    rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

    On rs6000, there are three 128 bit scalar floating point
    modes TFmode, IFmode and KFmode.  With some historical
    reasons, we defines them with different mode precisions,
    that is KFmode 126, TFmode 127 and IFmode 128.  But in
    fact all of them should have the same mode precision 128,
    this special setting has caused some issues like some
    unexpected failures mentioned in [1] and also made us have
    to introduce some workarounds, such as: the workaround in
    build_common_tree_nodes for KFmode 126, the workaround in
    range_compatible_p for same mode but different precision
    issue.

    This patch is to make these three 128 bit scalar floating
    point modes TFmode, IFmode and KFmode have 128 bit mode
    precision, and keep the order same as previous in order
    to make machine independent parts of the compiler not try
    to widen IFmode to TFmode.  Besides, build_common_tree_nodes
    adopts the newly added hook mode_for_floating_type so we
    don't need to worry about unexpected mode for long double
    type node.

    In function convert_mode_scalar, with the proposed change,
    it adopts sext_optab for converting ieee128 format mode to
    ibm128 format mode while trunc_optab for converting ibm128
    format mode to ieee128 format mode.  Thus this patch removes
    useless extend and trunc optab supports, supplements new
    define_expands expandkftf2 and trunctfkf2 to align with
    convert_mode_scalar implementation.  It also unnames two
    define_insn_and_split to avoid conflicts and make them more
    clear.  Considering the current implementation that there is
    no chance to have KF <-> IF conversion (since either of them
    would be TF already), it adds two dummy define_expands to
    assert this.

    [1] https://inbox.sourceware.org/gcc-patches/
        718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/

            PR target/112993

    gcc/ChangeLog:

            * config/rs6000/rs6000-modes.def (IFmode, KFmode, TFmode): Define
            with FLOAT_MODE instead of FRACTIONAL_FLOAT_MODE, don't use special
            precisions any more.
            (rs6000-modes.h): Remove include.
            * config/rs6000/rs6000-modes.h: Remove.
            * config/rs6000/rs6000.h (rs6000-modes.h): Remove include.
            * config/rs6000/t-rs6000: Remove rs6000-modes.h include.
            * config/rs6000/rs6000.cc (rs6000_option_override_internal):
Replace
            all uses of FLOAT_PRECISION_TFmode with 128.
            (rs6000_c_mode_for_floating_type): Likewise.
            * config/rs6000/rs6000.md (define_expand extendiftf2): Remove.
            (define_expand extendifkf2): Remove.
            (define_expand extendtfkf2): Remove.
            (define_expand trunckftf2): Remove.
            (define_expand trunctfif2): Remove.
            (define_expand extendtfif2): Add new assertion.
            (define_expand expandkftf2): New.
            (define_expand trunciftf2): Add new assertion.
            (define_expand trunctfkf2): New.
            (define_expand truncifkf2): Change with gcc_unreachable.
            (define_expand expandkfif2): New.
            (define_insn_and_split extendkftf2): Rename to  ...
            (define_insn_and_split *extendkftf2): ... this.
            (define_insn_and_split trunctfkf2): Rename to ...
            (define_insn_and_split *extendtfkf2): ... this.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r15-2085-gde6969fd311307e34904fc1f85603a9d92938974
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:16:59 2024 -0500

    fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

    Previously effective target fortran_real_c_float128 never
    passes on Power regardless of the default 128 long double
    is ibmlongdouble or ieeelongdouble.  It's due to that TF
    mode is always used for kind 16 real, which has precision
    127, while the node float128_type_node for c_float128 has
    128 type precision, get_real_kind_from_node can't find a
    matching as it only checks gfc_real_kinds[i].mode_precision
    and type precision.

    With changing TFmode/IFmode/KFmode to have the same mode
    precision 128, now fortran_real_c_float12 can pass with
    ieeelongdouble enabled by default and test cases guarded
    with it get tested accordingly.  But with ibmlongdouble
    enabled by default, since TFmode has precision 128 which
    is the same as type precision 128 of float128_type_node,
    get_real_kind_from_node considers kind for TFmode matches
    float128_type_node, but it's wrong as at this time point
    TFmode is with ibm extended format.  So this patch is to
    teach get_real_kind_from_node to check one more field which
    can be differentiable from the underlying real format, it
    can avoid the unexpected matching when there more than one
    modes have the same precisoin.

            PR target/112993

    gcc/fortran/ChangeLog:

            * trans-types.cc (get_real_kind_from_node): Consider the case where
            more than one modes have the same precision.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r15-2086-gfa86f510f51e6d940a28ea997fca3a6e3f50b4d3
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:17:42 2024 -0500

    ranger: Revert the workaround introduced in PR112788 [PR112993]

    This reverts commit r14-6478-gfda8e2f8292a90 "range:
    Workaround different type precision between _Float128 and
    long double [PR112788]" as the fixes for PR112993 make
    all 128 bits scalar floating point have the same 128 bit
    precision, this workaround isn't needed any more.

            PR target/112993

    gcc/ChangeLog:

            * value-range.h (range_compatible_p): Remove the workaround on
            different type precision between _Float128 and long double.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r15-2087-gb5c813ed6035cf6ef831927e66e184a5847afbe6
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:19:00 2024 -0500

    tree: Remove KFmode workaround [PR112993]

    The fix for PR112993 makes KFmode have 128 bit mode precision,
    we don't need this workaround to fix up the type precision any
    more, and just go with mode precision.  So this patch is to
    remove KFmode workaround.

            PR target/112993

    gcc/ChangeLog:

            * tree.cc (build_common_tree_nodes): Drop the workaround for rs6000
            KFmode precision adjustment.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 116170, which changed state.

Bug 116170 Summary: [15 regression] ICE unrecognizable insn since r15-2084-g33dca0a4c1c421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED