Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Hi! On Wed, Jun 03, 2020 at 04:46:12PM +0200, Richard Biener wrote: > On Wed, Jun 3, 2020 at 4:17 PM David Edelsohn wrote: > > On Wed, Jun 3, 2020 at 9:41 AM Richard Sandiford > > wrote: > > > Well, it seems unfortunate to have to do that. > > > > > > I think Martin's powerpc patch is the correc

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

be nice > > >> > to have testsuite coverage for the FAILs, and maybe we have that > > >> > already. > > >> > > >> Hello. > > >> > > >> There's the suggested patch that survives bootstrap on ppc64le-linux-gnu > > >> and p

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

>> > >> Hello. > >> > >> There's the suggested patch that survives bootstrap on ppc64le-linux-gnu > >> and passes test-suite. > > > > OK, so can you please re-post the version of the VEC_COND_EXPR > > patch that uses a regular I

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

-linux-gnu >> and passes test-suite. > > OK, so can you please re-post the version of the VEC_COND_EXPR > patch that uses a regular IFN (without the static non-FAIL checking) > in a new thread? If there's no OK from rs6000 maintainers to remove > the FAILs then we

[PATCH] V2: Lower VEC_COND_EXPR into internal functions.

-pass.h (make_pass_gimple_isel): New. * tree-ssa-forwprop.c (pass_forwprop::execute): Do not forward to already lowered VEC_COND_EXPR. * tree-vect-generic.c (expand_vector_divmod): Expand to SSA_NAME. (expand_vector_condition): Expand tcc_comparison of a VEC_COND_EXPR

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

tstrap/test? I think it would be nice > > to have testsuite coverage for the FAILs, and maybe we have that > > already. > > Hello. > > There's the suggested patch that survives bootstrap on ppc64le-linux-gnu > and passes test-suite. OK, so can you please re-post th

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On 6/2/20 1:09 PM, Richard Biener wrote: So please be constructive. Like, provide a testcase that ICEs with the FAILs replaced by gcc_unreachable (). Martin, may I suggest to do this replacement and bootstrap/test? I think it would be nice to have testsuite coverage for the FAILs, and maybe we

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

practice. At that time, > > the corresponding expand code was: > > I, and I think most other people, thought it was allowed to FAIL (and > I still do). > > > rtx > > expand_vec_cond_expr (tree vec_cond_expr, rtx target) > > [ snip ] > > So this was buggy.

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

that just means that the powerpc bug has been there since 2004, > assuming these FAILs can actually trigger in practice. At that time, > the corresponding expand code was: I, and I think most other people, thought it was allowed to FAIL (and I still do). > rtx > expand_vec_cond_expr (tree ve

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

llowed” for vcond*. >> In fact it's the opposite. > > It has FAILed on rs6000 since 2004. But that just means that the powerpc bug has been there since 2004, assuming these FAILs can actually trigger in practice. At that time, the corresponding expand code was: /* Generate insns fo

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 06:26:55PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > Most patterns *do* FAIL on some target. We cannot rewind time. > > Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*. > In fact it's the opposite. It has FAILed on rs6000

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 06:05:14PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote: > >> Segher - do you actually know this code to guess why the patterns are > >> defensive? > > > > Yes. > > In that case, can you gi

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Segher Boessenkool writes: > On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote: >> Segher Boessenkool writes: >> > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote: >> >> Now it looks like that those verification also simply checks optab >> >> availability only but t

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote: > >> Now it looks like that those verification also simply checks optab > >> availability only but then this is just a preexisting iss

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Segher Boessenkool writes: > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote: >> So I tried to understand the circumstances the rs6000 patterns FAIL >> but FAILed ;) It looks like some outs of rs6000_emit_vector_cond_expr >> are unwarranted and the following should work: >> >> dif

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Segher Boessenkool writes: > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote: >> Now it looks like that those verification also simply checks optab >> availability only but then this is just a preexisting issue (and we can >> possibly build a testcase that FAILs RTL expansion for po

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote: > So I tried to understand the circumstances the rs6000 patterns FAIL > but FAILed ;) It looks like some outs of rs6000_emit_vector_cond_expr > are unwarranted and the following should work: > > diff --git a/gcc/config/rs6000/rs6000.

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote: > Now it looks like that those verification also simply checks optab > availability only but then this is just a preexisting issue (and we can > possibly build a testcase that FAILs RTL expansion for power...). > > So given that this

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Fri, May 29, 2020 at 2:17 PM Richard Biener wrote: > > On Thu, May 28, 2020 at 5:28 PM Richard Sandiford > wrote: > > > > Martin Liška writes: > > > Hi. > > > > > > There's a new patch that adds normal internal functions for the 4 > > > VCOND* functions. > > > > > > The patch that survives bo

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Thu, May 28, 2020 at 5:28 PM Richard Sandiford wrote: > > Martin Liška writes: > > Hi. > > > > There's a new patch that adds normal internal functions for the 4 > > VCOND* functions. > > > > The patch that survives bootstrap and regression > > tests on x86_64-linux-gnu and ppc64le-linux-gnu. >

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Martin Liška writes: > Hi. > > There's a new patch that adds normal internal functions for the 4 > VCOND* functions. > > The patch that survives bootstrap and regression > tests on x86_64-linux-gnu and ppc64le-linux-gnu. I think this has the same problem as the previous one. What I meant in yest

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

in Liska Date: Mon, 9 Mar 2020 13:23:03 +0100 Subject: [PATCH] Lower VEC_COND_EXPR into internal functions. gcc/ChangeLog: 2020-03-30 Martin Liska * expr.c (expand_expr_real_2): Put gcc_unreachable, we should reach this path. (do_store_flag): Likewise here. * inter

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On May 27, 2020 6:13:24 PM GMT+02:00, Richard Sandiford wrote: >Martin Liška writes: >> On 5/26/20 12:15 PM, Richard Sandiford wrote: >>> So longer-term, I think we should replace VCOND(U) with individual >ifns, >>> like for VCONDEQ. We could reduce the number of optabs needed by >>> canonicali

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Martin Liška writes: > On 5/26/20 12:15 PM, Richard Sandiford wrote: >> So longer-term, I think we should replace VCOND(U) with individual ifns, >> like for VCONDEQ. We could reduce the number of optabs needed by >> canonicalising greater-based tests to lesser-based tests. > > Hello. > > Thanks f

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

From: Martin Liska Date: Mon, 9 Mar 2020 13:23:03 +0100 Subject: [PATCH] Lower VEC_COND_EXPR into internal functions. gcc/ChangeLog: 2020-03-30 Martin Liska * expr.c (expand_expr_real_2): Put gcc_unreachable, we should reach this path. (do_store_flag): Likewise here. * internal-fn.c (vec_cond

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Richard Biener writes: > On Thu, May 21, 2020 at 10:17 PM Segher Boessenkool > wrote: >> >> Hi! >> >> On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote: >> > Adding Segher to CC, he can help us. >> >> Oh dear. Are you sure? >> >> > On 5/21/20 2:51 PM, Martin Liška wrote: >> > >Back to

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Thu, May 21, 2020 at 10:17 PM Segher Boessenkool wrote: > > Hi! > > On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote: > > Adding Segher to CC, he can help us. > > Oh dear. Are you sure? > > > On 5/21/20 2:51 PM, Martin Liška wrote: > > >Back to this I noticed that ppc64le target bu

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Hi! On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote: > Adding Segher to CC, he can help us. Oh dear. Are you sure? > On 5/21/20 2:51 PM, Martin Liška wrote: > >Back to this I noticed that ppc64le target build is broken due to: > >insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Adding Segher to CC, he can help us. Martin On 5/21/20 2:51 PM, Martin Liška wrote: Hi. Back to this I noticed that ppc64le target build is broken due to: g++  -fno-PIE -c   -g   -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narr

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Hi. Back to this I noticed that ppc64le target build is broken due to: g++ -fno-PIE -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -ped

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford wrote: > > Martin Liška writes: > > Hello. > > > > This is second attempt to get rid of tcc_comparison GENERIC trees > > to be used as the first argument of VEC_COND_EXPR. > > > > The patch attempts a

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford wrote: > > Martin Liška writes: > > Hello. > > > > This is second attempt to get rid of tcc_comparison GENERIC trees > > to be used as the first argument of VEC_COND_EXPR. > > > > The patch attempts a

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Martin Liška writes: > Hello. > > This is second attempt to get rid of tcc_comparison GENERIC trees > to be used as the first argument of VEC_COND_EXPR. > > The patch attempts achieves that in the following steps: > 1) veclower pass expands all tcc_comparison expression into

[stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

Hello. This is second attempt to get rid of tcc_comparison GENERIC trees to be used as the first argument of VEC_COND_EXPR. The patch attempts achieves that in the following steps: 1) veclower pass expands all tcc_comparison expression into a SSA_NAME 2) since that tcc_comparsion can't be

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

andps/vandnps/vorps). The problem is that after the last generic vector > lowering (where the VEC_COND_EXPR still compares two V4DF vectors and > has two V4DI last operands and V4DI result and so is considered ok) fre4 > folds the condition into constant, at which point the mid

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

On Mon, Feb 10, 2020 at 03:40:18PM +0100, Richard Biener wrote: > Hmm. Maybe with FP operands we can also try to implement the mask > as != 0.0 FP condition? Not sure if -1 (or 1) is enough non-NaNish to > not cause problems of course. Well, by the time we reach expansion, we have just the VECTO

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

andps/vandnps/vorps). The problem is that after the last generic vector > lowering (where the VEC_COND_EXPR still compares two V4DF vectors and > has two V4DI last operands and V4DI result and so is considered ok) fre4 > folds the condition into constant, at which point the mid

[PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

e the VEC_COND_EXPR still compares two V4DF vectors and has two V4DI last operands and V4DI result and so is considered ok) fre4 folds the condition into constant, at which point the middle-end during expansion will try vcond_mask_optab and fall back to trying to expand it as the constant vecto

Re: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR

On 29.11.19 15:46, Richard Sandiford wrote: > Thanks for doing this, looks good to me FWIW. I was seeing the same > failure for SVE but hadn't found time to look at it. Thank you all for the review. Committed as r278853. Frederik

Re: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR

; > > 2019-11-29 Frederik Harwath > > gcc/ > * gimple-match-head.c (maybe_resimplify_conditional_op): Use > generic_expr_could_trap_p to check if the condition of COND_EXPR or > VEC_COND_EXPR can trap. Thanks for doing this, looks good to me FWIW. I was

Re: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR (was: Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR)

tional_op): Use generic_expr_could_trap_p to check if the condition of COND_EXPR or VEC_COND_EXPR can trap. --- gcc/gimple-match-head.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c index 2996bade301..901

Re: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR (was: Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR)

On Fri, Nov 29, 2019 at 02:38:34PM +0100, Harwath, Frederik wrote: > 2019-11-29 Frederik Harwath > > gcc/ > * gimple-match-head.c (maybe_resimplify_conditional_op): use s/use/Use/ > generic_expr_could_trap_p to check if the condition of COND_EXPR or > VEC_

[PATCH] Fix ICE in re-simplification of VEC_COND_EXPR (was: Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR)

his has been discovered in the context of amdgcn is not really essential. Best regards, Frederik 2019-11-29 Frederik Harwath gcc/ * gimple-match-head.c (maybe_resimplify_conditional_op): use generic_expr_could_trap_p to check if the condition of COND_EXPR or VEC_COND_E

Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR

eed a COND_ADD. > condition for the inner vec_cond. Your fix looks reasonable but is > very badly formatted. Can you instead do > > if (op_Code == cOND_EPXR || op_code == vEC_COND_EXPR) >op_could_trap = generic_expr_could_trap (..) > else > op_could_trap = operation_could_trap_p (... > Sorry, sure! Thanks, Frederik

Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR

> introduced by revision r276659 > ("Allow COND_EXPR and VEC_COND_EXPR condtions to trap" by Ilya Leoshkevich) > of trunk and the vectorized code that is generated for amdgcn. > > If the function maybe_resimplify_conditional_op from gimple-match-head.c gets > called on a c

[PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR

Hi, currently, on trunk, the tests gcc.dg/vect/vect-cond-reduc-1.c and gcc.dg/pr68286.c fail when compiling for amdgcn-unknown-amdhsa. The reason seems to lie in the interaction of the changes that have been introduced by revision r276659 ("Allow COND_EXPR and VEC_COND_EXPR condtions to tra

Re: [PATCH v4 1/7] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

On Tue, Oct 1, 2019 at 3:27 PM Ilya Leoshkevich wrote: > > Right now gimplifier does not allow VEC_COND_EXPR's condition to trap > and introduces a temporary if this could happen, for example, generating > > _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; > _6 = VEC_C

[PATCH v4 1/7] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

Right now gimplifier does not allow VEC_COND_EXPR's condition to trap and introduces a temporary if this could happen, for example, generating _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; from GENERIC VEC_C

Re: [PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

trap > >> and introduces a temporary if this could happen, for example, generating > >> > >> _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; > >> _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; > >> > >> from GENERIC &g

Re: [PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

t;> >> _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; >> _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; >> >> from GENERIC >> >> VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) , >> { -1,

Re: [PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote: > > Right now gimplifier does not allow VEC_COND_EXPR's condition to trap > and introduces a temporary if this could happen, for example, generating > > _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; > _6 = VEC_C

[PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

Right now gimplifier does not allow VEC_COND_EXPR's condition to trap and introduces a temporary if this could happen, for example, generating _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; from GENERIC VEC_C

Re: [PATCH] Fix VEC_COND_EXPR expansion ICE (PR middle-end/91623)

On September 1, 2019 12:19:51 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs >with >EQ_EXPR/NE_EXPR are supported and vectorizer generates such >VEC_COND_EXPR, >but later on the condition is folded into

[PATCH] Fix VEC_COND_EXPR expansion ICE (PR middle-end/91623)

Hi! The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs with EQ_EXPR/NE_EXPR are supported and vectorizer generates such VEC_COND_EXPR, but later on the condition is folded into a VECTOR_CST and the VEC_COND_EXPR expansion code expands non-comparison conditions as LT_EXPR against

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

Jeff Law writes: > On 11/20/18 7:57 AM, Renlin Li wrote: >> Hi Richard, >> >> On 11/14/2018 02:59 PM, Richard Biener wrote: >>> On Fri, Nov 9, 2018 at 4:49 PM Renlin Li  wrote: Hi Richard, On 11/09/2018 11:48 AM, Richard Biener wrote: > On Thu, Nov 8, 2018 at 5:55 PM Renli

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

AMEs from same scalar pointer by loop vectorizer. > I can not directly compare the address as the are complicated with loop  > information. > > > By moving the functionality into forwprop, the complications are removed by  > the optimizers in between. > > This makes a sim

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

COND (cond, VAL, X) + MASK_STORE (PTR, -, MASK, Y) + + They could be combined into a single MASK_STORE with new mask. + The new mask is the combination of original mask and the value selection mask + in VEC_COND_EXPR. + + AND_MASK = MASK & cond + MASK_STORE (PTR, -

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

7;s not because of if-conversion but because SVE needs to > > mask _all_ > > loop operations that are not safe to execute with the loop_mask! > > > >> vect_a_10.6_6 = .MASK_LOAD (vectp_array.4_35, 4B, loop_mask_7); > >> a_10 = array[i_20]; > >>

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

= array[i_20]; vect__1.7_39 = vect_a_10.6_6 & vect_cst__38; _1 = a_10 & 1; vect__2.8_41 = vect_a_10.6_6 + vect_cst__40; _2 = a_10 + 1; vect__ifc__34.9_43 = VEC_COND_EXPR ; _ifc__34 = _1 != 0 ? _2 : a_10; .MASK_STORE (vectp_array.10_45, 4B, loop_mask_7, vect__ifc__34.9_43

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

would prefer to generated > >> conditional select and unconditional store to convert certain if statement > >> into: > >> > >> _ifc_1 = val > >> _ifc_2 = A[i] > >> val = cond? _ifc_1 : _ifc_2 > >> A[i] = val > >> > >&

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

= A[i] val = cond? _ifc_1 : _ifc_2 A[i] = val When the loop got vectorized, this pattern will be turned into MASK_LOAD, VEC_COND_EXPR and MASK_STORE. This could be improved. I'm somewhat confused - the vectorizer doesn't generate a masked store when if-conversion didn't create o

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

? _ifc_1 : _ifc_2 > A[i] = val > > When the loop got vectorized, this pattern will be turned into > MASK_LOAD, VEC_COND_EXPR and MASK_STORE. This could be improved. I'm somewhat confused - the vectorizer doesn't generate a masked store when if-conversion didn't create one

[RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

MASK_LOAD, VEC_COND_EXPR and MASK_STORE. This could be improved. The change here add a post processing function to combine the VEC_COND_EXPR expression into MASK_STORE, and delete related dead code. I am a little bit conservative here. I didn't change the default behavior of ifcvt to always gen

Re: [C++ PATCH] Fix constexpr VEC_COND_EXPR handling (PR c++/82781)

On 11/20/2017 02:42 AM, Jakub Jelinek wrote: Hi! VEC_COND_EXPR is handled in constexpr code like COND_EXPR, but that is wrong. VEC_COND_EXPR is more like an arbitrary arithmetics ternary operation, we need to compute all 3 arguments and based on the elements of the first argument pick up

[C++ PATCH] Fix constexpr VEC_COND_EXPR handling (PR c++/82781)

Hi! VEC_COND_EXPR is handled in constexpr code like COND_EXPR, but that is wrong. VEC_COND_EXPR is more like an arbitrary arithmetics ternary operation, we need to compute all 3 arguments and based on the elements of the first argument pick up elements of 2nd and 3rd arguments. The COND_EXPR

Re: [C++ PATCH] Fix ICE when dumping VEC_COND_EXPR (PR c++/80363)

On Mon, Apr 10, 2017 at 10:34 PM, Jakub Jelinek wrote: > Hi! > > The following testcase emits vec_cond_expr not supported by dump_expr > inside of error message. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, > ok for trunk? Ok. Richard. > 2

[C++ PATCH] Fix ICE when dumping VEC_COND_EXPR (PR c++/80363)

Hi! The following testcase emits vec_cond_expr not supported by dump_expr inside of error message. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-04-10 Jakub Jelinek PR c++/80363 * error.c (dump_expr): Handle VEC_COND_EXPR like

Re: [PATCH] Fix vector lowering of VEC_COND_EXPR with VECTOR_BOOLEAN_TYPE_P with scalar mode (PR tree-optimization/79734)

On Tue, 28 Feb 2017, Jakub Jelinek wrote: > Hi! > > This patch fixes ICE during lowering of VEC_COND_EXPR which has the > AVX512-ish [QHSD]Imode VECTOR_BOOLEAN_TYPE_P type (where the TYPE_SIZE > of the comp_inner_type and inner_type are different). > In addition, it attempts

[PATCH] Fix vector lowering of VEC_COND_EXPR with VECTOR_BOOLEAN_TYPE_P with scalar mode (PR tree-optimization/79734)

Hi! This patch fixes ICE during lowering of VEC_COND_EXPR which has the AVX512-ish [QHSD]Imode VECTOR_BOOLEAN_TYPE_P type (where the TYPE_SIZE of the comp_inner_type and inner_type are different). In addition, it attempts to expand it into efficient code when possible (by performing the

Re: [PATCH, PR middle-end/71279] Avoid folding vec_cond_expr into comparison

On Fri, May 27, 2016 at 11:02 AM, Ilya Enkovich wrote: > Hi, > > This patch disable transformation of VEC_COND_EXPR into comparison > which became invalid after boolean vectors introduciton. > > Bootstrapped and regtested for x86_64-pc-linux-gnu. OK for trunk > and gcc-6?

[PATCH, PR middle-end/71279] Avoid folding vec_cond_expr into comparison

Hi, This patch disable transformation of VEC_COND_EXPR into comparison which became invalid after boolean vectors introduciton. Bootstrapped and regtested for x86_64-pc-linux-gnu. OK for trunk and gcc-6? Thanks, Ilya -- gcc/ 2016-05-27 Ilya Enkovich PR middle-end/71279

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

016 6:02:27 PM GMT+02:00, Bin Cheng wrote: >>>>>Hi, >>>>>As PR69848 reported, GCC vectorizer now generates comparison outside of >>>>>VEC_COND_EXPR for COND_REDUCTION case, as below: >>>>> >>>>> _20 = vect__1.6_8 != { 0, 0, 0, 0 };

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

s PR69848 reported, GCC vectorizer now generates comparison outside of >>>>VEC_COND_EXPR for COND_REDUCTION case, as below: >>>> >>>> _20 = vect__1.6_8 != { 0, 0, 0, 0 }; >>>> vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0, 0, 0 }, vect_c_2.7_13>; &g

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

On Mon, May 16, 2016 at 10:09 AM, Bin.Cheng wrote: > On Fri, May 13, 2016 at 5:53 PM, Richard Biener > wrote: >> On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote: >>>Hi, >>>As PR69848 reported, GCC vectorizer now generates comparison outside of >>>VE

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

On Fri, May 13, 2016 at 5:53 PM, Richard Biener wrote: > On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote: >>Hi, >>As PR69848 reported, GCC vectorizer now generates comparison outside of >>VEC_COND_EXPR for COND_REDUCTION case, as below: >> >>

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote: >Hi, >As PR69848 reported, GCC vectorizer now generates comparison outside of >VEC_COND_EXPR for COND_REDUCTION case, as below: > > _20 = vect__1.6_8 != { 0, 0, 0, 0 }; > vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0,

[PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

Hi, As PR69848 reported, GCC vectorizer now generates comparison outside of VEC_COND_EXPR for COND_REDUCTION case, as below: _20 = vect__1.6_8 != { 0, 0, 0, 0 }; vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0, 0, 0 }, vect_c_2.7_13>; _21 = VEC_COND_EXPR <_20, ivtmp_17, _19>; Thi

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

just c_fully_fold_internal all the arguments, be ready for any future > > > further uses of VEC_COND_EXPR early? > > > > ..thus revive my earlier version of the patch that does it: > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > >

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

> further uses of VEC_COND_EXPR early? > > ..thus revive my earlier version of the patch that does it: > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2016-04-01 Marek Polacek > > PR c/70307 > * c-fold.c (c_fully_fold_internal): Handle VEC_

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

On Fri, Apr 01, 2016 at 06:17:57PM +0200, Jakub Jelinek wrote: > Those comparisons with truthvalue_*_node would fail and DTRT. > Or just c_fully_fold_internal all the arguments, be ready for any future > further uses of VEC_COND_EXPR early? ..thus revive my earlier version of the patch

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

-528,6 +528,23 @@ c_fully_fold_internal (tree expr, bool in_init, > > > >bool *maybe_const_operands, > > > > *maybe_const_itself &= op2_const_self; > > > >goto out; > > > > > > > >+case VEC_COND_EXPR: > &g

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

ol > > >*maybe_const_operands, > > > *maybe_const_itself &= op2_const_self; > > >goto out; > > > > > >+case VEC_COND_EXPR: > > >+ orig_op0 = op0 = TREE_OPERAND (expr, 0); > > >+ op1 = TREE_OPERAND (expr, 1); > > >+

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

; >goto out; > > > >+case VEC_COND_EXPR: > >+ orig_op0 = op0 = TREE_OPERAND (expr, 0); > >+ op1 = TREE_OPERAND (expr, 1); > >+ op2 = TREE_OPERAND (expr, 2); > >+ op0 = c_fully_fold_internal (op0, in_init, maybe_const_op

Re: [C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

On 04/01/2016 09:03 AM, Marek Polacek wrote: This is another case where a C_MAYBE_CONST_EXPR leaks into the gimplifier. Starting with r229128 and thus introduction of build_vec_cmp we now create VEC_COND_EXPR when building a vector comparison. The C_MAYBE_CONST_EXPR originated in

[C PATCH] Fix ICE with VEC_COND_EXPR and compound literals (PR c/70307)

This is another case where a C_MAYBE_CONST_EXPR leaks into the gimplifier. Starting with r229128 and thus introduction of build_vec_cmp we now create VEC_COND_EXPR when building a vector comparison. The C_MAYBE_CONST_EXPR originated in build_compound_literal when creating a COMPOUND_LITERAL_EXPR

[PATCH, PR tree-optimization/70251] Disable VEC_COND_EXPR transformation into VIEW_CONVERT_EXPR for scalar mask case

Hi, This patch disables two match.pd patterns which transform VEC_COND_EXPR into simple conversion in case it uses a scalar mask. The patch was bootstrapped and regtested on x86_64-pc-linux-gnu + separate check for new test on SDE. OK for trunk? Thanks, Ilya -- gcc/ 2016-03-17 Ilya Enkovich

Re: [PATCH, PR tree-optimization/70251] Disable VEC_COND_EXPR transformation into VIEW_CONVERT_EXPR for scalar mask case

On Thu, Mar 17, 2016 at 11:23 AM, Ilya Enkovich wrote: > Hi, > > This patch disables two match.pd patterns which transform > VEC_COND_EXPR into simple conversion in case it uses a scalar mask. > The patch was bootstrapped and regtested on x86_64-pc-linux-gnu + > separate check f

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Mar 2, 2016 at 1:10 PM, Jakub Jelinek wrote: > On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote: >> On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote: >> > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote: >> >> I got >> >> >> >> FAIL: c-c++-common/vector-compare-4

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Mar 02, 2016 at 01:10:51PM +0100, Jakub Jelinek wrote: > On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote: > > On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote: > > > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote: > > >> I got > > >> > > >> FAIL: c-c++-common/ve

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote: > On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote: > > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote: > >> I got > >> > >> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for > >> warnings, line 17) > >> FAI

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote: > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote: >> I got >> >> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for >> warnings, line 17) >> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for >> warnings, line

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote: > I got > > FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for > warnings, line 17) > FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for > warnings, line 18) > FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Jan 27, 2016 at 9:45 AM, Marek Polacek wrote: > On Wed, Jan 27, 2016 at 10:02:36AM -0700, Jeff Law wrote: >> On 01/27/2016 12:26 AM, Marek Polacek wrote: >> >Ping. >> > >> >On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote: >> >>On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Jan 27, 2016 at 10:02:36AM -0700, Jeff Law wrote: > On 01/27/2016 12:26 AM, Marek Polacek wrote: > >Ping. > > > >On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote: > >>On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote: > >>>The C front-end changes are OK. > >> > >>Jas

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On 01/27/2016 12:26 AM, Marek Polacek wrote: Ping. On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote: On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote: The C front-end changes are OK. Jason, is the C++ part of this patch here

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

Ping. On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote: > On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote: > > The C front-end changes are OK. > > Jason, is the C++ part of this patch here > > (which is identical

Re: [PATCH] Avoid unnecessary creation of VEC_COND_EXPR in the vectorizer

On January 22, 2016 11:09:06 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >I've noticed we create a VEC_COND_EXPR tree just to grab the arguments >from >it to construct a ternary gimple assign. > >The following patch fixes that by creating the ternary gimple assig

[PATCH] Avoid unnecessary creation of VEC_COND_EXPR in the vectorizer

Hi! I've noticed we create a VEC_COND_EXPR tree just to grab the arguments from it to construct a ternary gimple assign. The following patch fixes that by creating the ternary gimple assign directly. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-01-22 Jakub Je

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote: > The C front-end changes are OK. Jason, is the C++ part of this patch here (which is identical to the change in the C FE) ok? Also, not sure about backporting this, maybe just

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

On Wed, 13 Jan 2016, Marek Polacek wrote: > On Wed, Jan 13, 2016 at 06:53:06PM +, Joseph Myers wrote: > > Will -Wsign-compare warnings be generated for the implicit signed / > > unsigned conversions in comparisons, as for scalar comparisons? > > Good point. No, with the previous patch -Wsig

<    1   2   3   >