public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marc Glisse <marc.glisse@inria.fr>
To: Christophe Lyon <christophe.lyon@linaro.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
	 GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: VEC_COND_EXPR optimizations v2
Date: Thu, 6 Aug 2020 11:05:56 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.23.453.2008061105440.8021@stedding.saclay.inria.fr> (raw)
In-Reply-To: <CAKdteOYB5_WkzbvMMNyRiHAGbrTAW-zY_aQqi91ReTpc5VQ78Q@mail.gmail.com>

On Thu, 6 Aug 2020, Christophe Lyon wrote:

>>> 2020-08-05  Marc Glisse  <marc.glisse@inria.fr>
>>>
>>>         PR tree-optimization/95906
>>>         PR target/70314
>>>         * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
>>>         (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
>>>         (op (c ? a : b)): Update to match the new transformations.
>>>
>>>         * gcc.dg/tree-ssa/andnot-2.c: New file.
>>>         * gcc.dg/tree-ssa/pr95906.c: Likewise.
>>>         * gcc.target/i386/pr70314.c: Likewise.
>>>
>
> I think this patch is causing several ICEs on arm-none-linux-gnueabihf
> --with-cpu cortex-a9 --with-fpu neon-fp16:
>  Executed from: gcc.c-torture/compile/compile.exp
>    gcc.c-torture/compile/20160205-1.c   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
> compiler error)
>    gcc.c-torture/compile/20160205-1.c   -O3 -g  (internal compiler error)
>  Executed from: gcc.dg/dg.exp
>    gcc.dg/pr87746.c (internal compiler error)
>  Executed from: gcc.dg/tree-ssa/tree-ssa.exp
>    gcc.dg/tree-ssa/ifc-cd.c (internal compiler error)

I tried a cross from x86_64-linux with current master

.../configure --target=arm-none-linux-gnueabihf --enable-languages=c,c++ --with-system-zlib --disable-nls --with-cpu=cortex-a9 --with-fpu=neon-fp16
make

it stops at some point with an error, but I have xgcc and cc1 in
build/gcc.

I copied 2 of the testcases and compiled

./xgcc pr87746.c -Ofast -S -B.
./xgcc -O3 -fdump-tree-ifcvt-details-blocks-details ifc-cd.c -S -B.

without getting any ICE.

Is there a machine on the compile farm where this is easy to reproduce?
Or could you attach the .optimized dump that corresponds to the
backtrace below? It looks like we end up with a comparison with an
unexpected return type.

>  Executed from: gcc.dg/vect/vect.exp
>    gcc.dg/vect/pr59591-1.c (internal compiler error)
>    gcc.dg/vect/pr59591-1.c -flto -ffat-lto-objects (internal compiler error)
>    gcc.dg/vect/pr86927.c (internal compiler error)
>    gcc.dg/vect/pr86927.c -flto -ffat-lto-objects (internal compiler error)
>    gcc.dg/vect/slp-cond-5.c (internal compiler error)
>    gcc.dg/vect/slp-cond-5.c -flto -ffat-lto-objects (internal compiler error)
>    gcc.dg/vect/vect-23.c (internal compiler error)
>    gcc.dg/vect/vect-23.c -flto -ffat-lto-objects (internal compiler error)
>    gcc.dg/vect/vect-24.c (internal compiler error)
>    gcc.dg/vect/vect-24.c -flto -ffat-lto-objects (internal compiler error)
>    gcc.dg/vect/vect-cond-reduc-6.c (internal compiler error)
>    gcc.dg/vect/vect-cond-reduc-6.c -flto -ffat-lto-objects (internal
> compiler error)
>
> Backtrace for gcc.c-torture/compile/20160205-1.c   -O3
> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions
> during RTL pass: expand
> /gcc/testsuite/gcc.c-torture/compile/20160205-1.c:2:5: internal
> compiler error: in do_store_flag, at expr.c:12259
> 0x8feb26 do_store_flag
>        /gcc/expr.c:12259
> 0x900201 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
>        /gcc/expr.c:9617
> 0x908cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
>        /gcc/expr.c:10159
> 0x91174e expand_expr
>        /gcc/expr.h:282
> 0x91174e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
> rtx_def**, expand_modifier)
>        /gcc/expr.c:8065
> 0x8ff543 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
>        /gcc/expr.c:9950
> 0x908cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
>        /gcc/expr.c:10159
> 0x91174e expand_expr
>        /gcc/expr.h:282
> 0x91174e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
> rtx_def**, expand_modifier)
>        /gcc/expr.c:8065
> 0x8ff543 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
>        /gcc/expr.c:9950
> 0x908cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
>        /gcc/expr.c:10159
> 0x91174e expand_expr
>        /gcc/expr.h:282
> 0x91174e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
> rtx_def**, expand_modifier)
>        /gcc/expr.c:8065
> 0x8ff543 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
>        /gcc/expr.c:9950
> 0x908cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
>        /gcc/expr.c:10159
> 0x91174e expand_expr
>        /gcc/expr.h:282
> 0x91174e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
> rtx_def**, expand_modifier)
>        /gcc/expr.c:8065
> 0x8ff543 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
>        /gcc/expr.c:9950
> 0x908cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
>        /gcc/expr.c:10159
> 0x91174e expand_expr
>        /gcc/expr.h:282
>
> Christophe

-- 
Marc Glisse

  reply	other threads:[~2020-08-06  9:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  7:49 VEC_COND_EXPR optimizations Marc Glisse
2020-07-31 11:18 ` Richard Sandiford
2020-07-31 11:38   ` Marc Glisse
2020-07-31 11:43     ` Richard Biener
2020-07-31 11:57       ` Marc Glisse
2020-07-31 12:50     ` Richard Sandiford
2020-07-31 12:59       ` Richard Biener
2020-07-31 13:01       ` Marc Glisse
2020-07-31 13:13         ` Marc Glisse
2020-07-31 11:35 ` Richard Biener
2020-07-31 11:39   ` Richard Biener
2020-07-31 11:47     ` Richard Biener
2020-07-31 12:08       ` Richard Biener
2020-07-31 12:12       ` Marc Glisse
2020-08-05 13:32 ` VEC_COND_EXPR optimizations v2 Marc Glisse
2020-08-05 14:24   ` Richard Biener
2020-08-06  8:17     ` Christophe Lyon
2020-08-06  9:05       ` Marc Glisse [this message]
2020-08-06 11:25         ` Christophe Lyon
2020-08-06 11:42           ` Marc Glisse
2020-08-06 12:00             ` Christophe Lyon
2020-08-06 18:07               ` Marc Glisse
2020-08-07  6:38                 ` Richard Biener
2020-08-07  8:33                   ` Marc Glisse
2020-08-07  8:47                     ` Richard Biener
2020-08-07 12:15                       ` Marc Glisse
2020-08-07 13:04                         ` Richard Biener
2020-08-06 10:29       ` Richard Biener
2020-08-06 11:11         ` Marc Glisse

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=alpine.DEB.2.23.453.2008061105440.8021@stedding.saclay.inria.fr \
    --to=marc.glisse@inria.fr \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).