public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/meissner/heads/work068)] Fix SFmode subreg of DImode and TImode
@ 2021-09-10 20:26 Michael Meissner
  0 siblings, 0 replies; only message in thread
From: Michael Meissner @ 2021-09-10 20:26 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:5445918a9ba8a071d9dd6c90e641e7b6325519c0

commit 5445918a9ba8a071d9dd6c90e641e7b6325519c0
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Sep 10 16:26:36 2021 -0400

    Fix SFmode subreg of DImode and TImode
    
    I first noticed it in building the Spec 2017 wrf_r and blender_r
    benchmarks.  Once I applied this patch, I also noticed several of the
    tests now pass.
    
    This patch fixes the breakage in the PowerPC due to a recent change in SUBREG
    behavior.  While it is arguable that the patch that caused the breakage should
    be reverted, this patch should be a bandage to prevent these changes from
    happening again.
    
    The core of the problem is we need to treat SUBREG's of SFmode and SImode
    specially on the PowerPC.  This is due to the fact that SFmode values that are
    in the vector and floating point registers are represented as DFmode.  When we
    want to do a direct move between the GPR registers and the vector registers, we
    have to convert the value from the DFmode representation to/from the SFmode
    representation.
    
    By doing this special processing instead of doing the transfer via store and
    load, we were able to speed up the math library which at times want to use the
    SFmode values in a union, and do logical operations on it (to test exponent
    ranges, etc.) and then move it over to use as a floating point value.
    
    I did a bootstrap build on a little endian power9 system with and without the
    patch applied.  There was no regression in the tests.  I'm doing a build on a
    big endian power8 system, but it hasn't finished yet as I sent this email.  I
    will check on the big endian progress tomorrow morning.
    
    The following tests now pass once again with the test.
    
            C tests:
            ========
            gcc.c-torture/compile/20071102-1.c
            gcc.c-torture/compile/pr55921.c
            gcc.c-torture/compile/pr85945.c
            gcc.c-torture/execute/complex-3.c
            gcc.dg/atomic/c11-atomic-exec-1.c
            gcc.dg/atomic/c11-atomic-exec-2.c
            gcc.dg/atomic/c11-atomic-exec-4.c
            gcc.dg/atomic/c11-atomic-exec-5.c
            gcc.dg/c11-atomic-2.c
            gcc.dg/pr42475.c
            gcc.dg/pr47201.c
            gcc.dg/pr48335-1.c
            gcc.dg/torture/pr67741.c
            gcc.dg/tree-ssa/ssa-dom-thread-10.c
            gcc.dg/tsan/pr88030.c
            gcc.dg/ubsan/float-cast-overflow-atomic.c
            gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c
    
            C++ tests:
            ==========
            g++.dg/opt/alias1.C
            g++.dg/template/koenig6.C
            g++.dg/torture/pr40924.C
            tmpdir-g++.dg-struct-layout-1/t001
    
            Fortran tests:
            ==============
            gfortran.dg/array_constructor_type_22.f03
            gfortran.dg/array_function_6.f90
            gfortran.dg/derived_comp_array_ref_7.f90
            gfortran.dg/elemental_scalar_args_1.f90
            gfortran.dg/elemental_subroutine_1.f90
            gfortran.dg/inline_matmul_5.f90
            gfortran.dg/inline_matmul_8.f90
            gfortran.dg/inline_matmul_9.f90
            gfortran.dg/matmul_bounds_6.f90
            gfortran.dg/operator_1.f90
            gfortran.dg/past_eor.f90
            gfortran.dg/pr101121.f
            gfortran.dg/pr91552.f90
            gfortran.dg/spread_shape_1.f90
            gfortran.dg/typebound_operator_3.f03
            gfortran.dg/value_1.f90
            gfortran.fortran-torture/execute/entry_4.f90
            gfortran.fortran-torture/execute/intrinsic_dotprod.f90
            gfortran.fortran-torture/execute/intrinsic_matmul.f90
    
    2021-09-10  Michael Meissner  <meissner@linux.ibm.com>
    
    gcc/
    
            * config/rs6000/rs6000.c (rs6000_emit_move_si_sf_subreg): Deal
            with SUBREGs of TImode and DImode.

Diff:
---
 gcc/config/rs6000/rs6000.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b7ea1483da5..030d41bb5e4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10469,6 +10469,16 @@ rs6000_emit_move_si_sf_subreg (rtx dest, rtx source, machine_mode mode)
 	  return true;
 	}
 
+      /* In case we are given a SUBREG for a larger type, reduce it to
+	 SImode.  */
+      if (mode == SFmode && GET_MODE_SIZE (inner_mode) > 4)
+	{
+	  rtx tmp = gen_reg_rtx (SImode);
+	  emit_move_insn (tmp, gen_lowpart (SImode, source));
+	  emit_insn (gen_movsf_from_si (dest, tmp));
+	  return true;
+	}
+
       if (mode == SFmode && inner_mode == SImode)
 	{
 	  emit_insn (gen_movsf_from_si (dest, inner_source));


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-09-10 20:26 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-10 20:26 [gcc(refs/users/meissner/heads/work068)] Fix SFmode subreg of DImode and TImode Michael Meissner

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).