Re: [PATCH 12/43] i386: Emulate MMX vec_dupv2si with SSE
All these patches from HJL have no testcases. Are they even sutable for gcc 9
at this stage
Original message
From: Uros Bizjak
Date: 11/02/2019 12:51 (GMT+00:00)
To: "H.J. Lu"
Cc: GCC Patches
Subject: Re: [PATCH 12/43] i386: Emulate MMX vec_dupv2si with SSE
On Mon, Feb 11, 2019 at 1:26 PM H.J. Lu wrote:
>
> On Sun, Feb 10, 2019 at 11:25 PM Uros Bizjak wrote:
> >
> > On Mon, Feb 11, 2019 at 2:04 AM H.J. Lu wrote:
> > >
> > > On Sun, Feb 10, 2019 at 1:49 PM Uros Bizjak wrote:
> > > >
> > > > On Sun, Feb 10, 2019 at 10:45 PM Uros Bizjak wrote:
> > > >
> > > > > > > > + [(const_int 0)]
> > > > > > > > +{
> > > > > > > > + /* Emulate MMX vec_dupv2si with SSE vec_dupv4si. */
> > > > > > > > + rtx op0 = gen_rtx_REG (V4SImode, REGNO (operands[0]));
> > > > > > > > + rtx insn = gen_vec_dupv4si (op0, operands[1]);
> > > > > > > > + emit_insn (insn);
> > > > > > > > + DONE;
> > > > > > >
> > > > > > > Please write this simple RTX explicitly in the place of
> > > > > > > (const_int 0) above.
> > > > > >
> > > > > > rtx insn = gen_vec_dupv4si (op0, operands[1]);
> > > > > >
> > > > > > is easy. How do I write
> > > > > >
> > > > > > rtx op0 = gen_rtx_REG (V4SImode, REGNO (operands[0]));
> > > > > >
> > > > > > in place of (const_int 0)?
> > > > >
> > > > > [(set (match_dup 2)
> > > > > (vec_duplicate:V4SI (match_dup 1)))]
> > > > >
> > > > > with
> > > > >
> > > > > "operands[2] = gen_rtx_REG (V4SImode, REGNO (operands[0]));"
> > > > >
> > > > > or even better:
> > > > >
> > > > > "operands[2] = gen_lowpart (V4SImode, operands[0]);"
> > > > >
> > > > > in the preparation statement.
> > > >
> > > > Even shorter is
> > > >
> > > > "operands[0] = gen_lowpart (V4SImode, operands[0]);"
> > > >
> > > > and use (match_dup 0) instead of (match_dup 2) in the RTX.
> > > >
> > > > There is plenty of examples throughout sse.md.
> > > >
> > >
> > > This works:
> > >
> > > (define_insn_and_split "*vec_dupv2si"
> > > [(set (match_operand:V2SI 0 "register_operand" "=y,x,Yv")
> > > (vec_duplicate:V2SI
> > > (match_operand:SI 1 "register_operand" "0,0,Yv")))]
> > > "TARGET_MMX || TARGET_MMX_WITH_SSE"
> > > "@
> > > punpckldq\t%0, %0
> > > #
> > > #"
> > > "TARGET_MMX_WITH_SSE && reload_completed"
> > > [(set (match_dup 0)
> > > (vec_duplicate:V4SI (match_dup 1)))]
> > > "operands[0] = gen_rtx_REG (V4SImode, REGNO (operands[0]));"
> > > [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")
> > > (set_attr "type" "mmxcvt,ssemov,ssemov")
> > > (set_attr "mode" "DI,TI,TI")])
> >
> > If it works, then gen_lowpart is preferred due to extra checks.
> > However, it would result in a paradoxical subreg, so I wonder if these
> > extra checks allow this transformation.
>
> gen_lowpart dosn't work:
Ah, we need lowpart_subreg after reload.
Uros.
Re: [PATCH 29/43] i386: Emulate MMX ssse3_pmaddubsw with SSE
what about testcases? for these
Original message
From: Uros Bizjak
Date: 10/02/2019 12:26 (GMT+00:00)
To: "H.J. Lu"
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 29/43] i386: Emulate MMX ssse3_pmaddubsw with SSE
On 2/10/19, H.J. Lu wrote:
> Emulate MMX ssse3_pmaddubsw with SSE. Only SSE register source operand
> is allowed.
>
> PR target/89021
> * config/i386/sse.md (ssse3_pmaddubsw): Add SSE emulation.
OK.
Uros.
> ---
> gcc/config/i386/sse.md | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 4bcfd3fc272..8b13a76da72 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -15666,17 +15666,17 @@
> (set_attr "mode" "TI")])
>
> (define_insn "ssse3_pmaddubsw"
> - [(set (match_operand:V4HI 0 "register_operand" "=y")
> + [(set (match_operand:V4HI 0 "register_operand" "=y,x,Yv")
> (ss_plus:V4HI
> (mult:V4HI
> (zero_extend:V4HI
> (vec_select:V4QI
> - (match_operand:V8QI 1 "register_operand" "0")
> + (match_operand:V8QI 1 "register_operand" "0,0,Yv")
> (parallel [(const_int 0) (const_int 2)
> (const_int 4) (const_int 6)])))
> (sign_extend:V4HI
> (vec_select:V4QI
> - (match_operand:V8QI 2 "nonimmediate_operand" "ym")
> + (match_operand:V8QI 2 "nonimmediate_operand" "ym,x,Yv")
> (parallel [(const_int 0) (const_int 2)
> (const_int 4) (const_int 6)]
> (mult:V4HI
> @@ -15688,13 +15688,17 @@
> (vec_select:V4QI (match_dup 2)
> (parallel [(const_int 1) (const_int 3)
> (const_int 5) (const_int 7)]))]
> - "TARGET_SSSE3"
> - "pmaddubsw\t{%2, %0|%0, %2}"
> - [(set_attr "type" "sseiadd")
> + "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
> + "@
> + pmaddubsw\t{%2, %0|%0, %2}
> + pmaddubsw\t{%2, %0|%0, %2}
> + vpmaddubsw\t{%2, %1, %0|%0, %1, %2}"
> + [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")
> + (set_attr "type" "sseiadd")
> (set_attr "atom_unit" "simul")
> (set_attr "prefix_extra" "1")
> (set (attr "prefix_rex") (symbol_ref "x86_extended_reg_mentioned_p
> (insn)"))
> - (set_attr "mode" "DI")])
> + (set_attr "mode" "DI,TI,TI")])
>
> (define_mode_iterator PMULHRSW
> [V4HI V8HI (V16HI "TARGET_AVX2")])
> --
> 2.20.1
>
>
Re: [
Looks like it fixed an GO Libs failure as well I was having Original message From: Jeff Law Date: 29/10/2018 15:56 (GMT+00:00) To: Segher Boessenkool , Andrew Pinski Cc: GCC Patches Subject: Re: [ On 10/29/18 1:49 AM, Segher Boessenkool wrote: > On Mon, Oct 29, 2018 at 12:31:28AM -0700, Andrew Pinski wrote: >>> PR rtl-optimization/87701 >>> PR rtl-optimization/87780 >>> * combine.c (make_more_copies): Rewrite. >> >> I think a better changelog would be :): >> * combine.c (make_more_copies): Rewrite to be simplier. > > But it is not simpler at all now: *not* removing old notes while changing > RTL instructions is a very bad idea often; and modifying instructions > while not being very careful upsets DF. It may *look* simple now ;-) FWIW, it looks like cr16 ran to completion this morning :-) Jeff
Re: Fold more boolean expressions
Original message From: MCC CS Date: 02/10/2018 14:38 (GMT+00:00) To: gcc-patches@gcc.gnu.org Subject: Re: Fold more boolean expressions Thanks a lot!
Re: bootstrap -O3 failure libgo on x64_86
Ian I've bootstrapped gcc 9 with gcc 8 again and I'm unable to recreate failure boostrapping with gcc 9 so ignore I'll report if happens again Graham Original message From: Ian Lance Taylor via gcc-patches Date: 15/09/2018 16:01 (GMT+00:00) To: graham stott Cc: gcc-patches Subject: Re: bootstrap -O3 failure libgo on x64_86 On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches wrote: > Hi > Fails due to undefind symbols runtime.* > O2 works I tried my best guess at recreating the problem, and everything worked fine. Please tell us exactly what you did and exactly what happened. Thanks. Ian
Re: bootstrap -O3 failure libgo on x64_86
Ian A simple bootstrap using gcc 8 as host compiler works with default configuration all langs+ada. Now trying using gcc 9 host from a week ago Will tty elimate which configue opts cause problem Graham Original message From: Ian Lance Taylor via gcc-patches Date: 15/09/2018 16:01 (GMT+00:00) To: graham stott Cc: gcc-patches Subject: Re: bootstrap -O3 failure libgo on x64_86 On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches wrote: > Hi > Fails due to undefind symbols runtime.* > O2 works I tried my best guess at recreating the problem, and everything worked fine. Please tell us exactly what you did and exactly what happened. Thanks. Ian
bootstrap -O3 failure libgo on x64_86
Hi Fails due to undefind symbols runtime.* O2 works
bootstrap with --werror=yes fails
Heads Due too -Wabi empty class std::intergal_constant warning compiling libstdc++/c++/cxx11-shim_facets.cc Graham
Re: [patch, fortran] Handling of .and. and .or. expressions
if i read this correctly it appears that IMPURE/PURE are not the normal pure attribute used by gcc but some entirely diff attribute specific to FORTANso people are taking about different things Original message From: Steve Kargl Date: 16/06/2018 17:38 (GMT+00:00) To: Janus Weil Cc: Janne Blomqvist , Thomas Koenig , fort...@gcc.gnu.org, gcc-patches Subject: Re: [patch, fortran] Handling of .and. and .or. expressions On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > > > Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > : > >> But at least for pure functions, this optimization looks Ok. > >> > > > >Why is everyone fixated on PURE vs IMPURE functions? > > Simply because it makes a difference in this context! It does not! A function marked as PURE by a programmer must meet certain requirement of the Fortran standard. An unmarked function or a function marked as IMPURE can still meet those same requirements. Marking something as IMPURE has only a single requirement in the standard. An impure elemental procedure processes array arguments in array element order. That's it. Marking a function as IMPURE does not mean the function has side effects. It does not mean that a function must be evaluated for each reference. Are you advocating that gfortran must evaluate ping() twice for impure real function ping() end function ping x = ping() + 0 * ping() end -- Steve
Re: O3 bootstraps fail on x86-64
It's --disable-libsanitizer that works not --disable-asan I got that wrong Original message From: graham stott via gcc-patches <gcc-patches@gcc.gnu.org> Date: 19/05/2018 10:30 (GMT+00:00) To: gcc-patches <gcc-patches@gcc.gnu.org> Subject: O3 bootstraps fail on x86-64 O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
Re: O3 bootstraps fail on x86-64
Disabling asan the build works Original message From: graham stott via gcc-patches <gcc-patches@gcc.gnu.org> Date: 19/05/2018 10:30 (GMT+00:00) To: gcc-patches <gcc-patches@gcc.gnu.org> Subject: O3 bootstraps fail on x86-64 O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
O3 bootstraps fail on x86-64
O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
gcc 8 trunk broken O3 on x86_64
All Just a heads the trunk has been broken since about Weds most files fail compare during bootstrap at O3 but pass at O2 My last succesful boostrap at O3 was Tuesday I no idea which commit caused it Graham
