be directly expandable.
The following keeps the intermediate internal function rewrite
given gimple_expand_vec_cond_expr still performs some optimizations
which eventually should move to vector lowering or match.pd, but
simplifies it down to always expand VEC_COND_EXPR to .VCOND_MASK.
Bootstrapped
n expression OP0 CODE OP1 by
- querying optab if the following expression:
- VEC_COND_EXPR< OP0 CODE OP1, {-1,...}, {0,...}>
- can be expanded. */
static tree
expand_vector_comparison (gimple_stmt_iterator *gsi, tree type, tree op0,
-
be directly expandable.
The following keeps the intermediate internal function rewrite
given gimple_expand_vec_cond_expr still performs some optimizations
which eventually should move to vector lowering or match.pd, but
simplifies it down to always expand VEC_COND_EXPR to .VCOND_MASK.
Bootstrapped
On 2/29/24 01:35, Richard Biener wrote:
The following amends the PR114070 fix to optimistically allow
the folding when we cannot expand the current vec_cond using
vcond_mask and we're still before vector lowering. This leaves
a small window between vectorization and lowering where we could
br
On Thu, 29 Feb 2024, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote:
> > That said, the quick experiment shows this isn't anything for stage4.
>
> The earlier the vector lowering is moved in the pass list, the higher
> are the possibilities that match.pd or
On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote:
> That said, the quick experiment shows this isn't anything for stage4.
The earlier the vector lowering is moved in the pass list, the higher
are the possibilities that match.pd or some other optimization reintroduces
unsupportable ve
On Thu, 29 Feb 2024, Richard Biener wrote:
> The following amends the PR114070 fix to optimistically allow
> the folding when we cannot expand the current vec_cond using
> vcond_mask and we're still before vector lowering. This leaves
> a small window between vectorization and lowering where we c
The following amends the PR114070 fix to optimistically allow
the folding when we cannot expand the current vec_cond using
vcond_mask and we're still before vector lowering. This leaves
a small window between vectorization and lowering where we could
break vec_conds that can be expanded via vcond{
The following avoids type inconsistencies in .COND_op generated by
simplifications of VEC_COND_EXPRs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/112469
* match.pd (cond ? op a : b -> .COND_op (cond, a, b)): Add
missing view_converts.
> Likewise, a C cst_vector_mask_p could check each element rather than the catch
> all "integer_zerop || integer_all_onesp".
Yes, you'd want to know whether the constant bit pattern covers a
vector mode (and which)
making lanes all ones or zeros.
> I agree with gimple-isel
eck each element rather than the catch
all "integer_zerop || integer_all_onesp".
I agree with gimple-isel replacing VEC_COND_EXPR when it's supported in
hardware,
just like .FMA is inserted to replace the universal MULT_EXPR/PLUS_EXPR tree
codes,
the question is whether vec_cond_e
et
can efficiently(!) do the operation we like to use. In this particular
case it would be vec_cond_mask support for the created VEC_COND_EXPR.
We also have to avoid doing this after ISEL.
Note all original types are data types while you need a mask type for
the selector which in turn means you will a
22-05-23 Roger Sayle
gcc/ChangeLog
PR tree-optimization/96912
* match.pd (vector_mask_p): New predicate to identify vectors
where every element must be zero or all ones.
(bit_xor (bit_and (bit_xor ...) ...) ...): Recognize a VEC_COND_EXPR
expressed as
movcc when the -march
> doesn't provide a suitable instruction. This patch provides that
> functionality to all targets in the middle-end, allowing the vectorizer(s)
> to safely assume support for VEC_COND_EXPR (when the target has suitable
> vector logic instructions).
>
&
the middle-end, allowing the vectorizer(s)
to safely assume support for VEC_COND_EXPR (when the target has suitable
vector logic instructions).
I should point out (for the record) that the new expand_vec_cond_expr
function in expr.cc is very different from the function of the same name
removed by M
/i386/avx512vl-pr54700-2b.C: New test.
> * gcc.target/i386/avx512vl-pr100648.c: New test.
--
BR,
Hongtao
From 354edbe6ae2269d3c980c3efefc9fcd9851ed5bc Mon Sep 17 00:00:00 2001
From: liuhongt
Date: Mon, 24 May 2021 10:57:52 +0800
Subject: [PATCH 2/2] [i386] For 128/256-bit vec_cond_e
Hi:
This patch is about to add define_insn_and_split to convert avx512
mask mov back to pblendv instructions when mask operand is (lt: reg
const0_rtx).
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/100648
* config/i386/sse.md
On April 27, 2021 5:22:56 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On April 27, 2021 5:12:35 PM GMT+02:00, Richard Sandiford
> wrote:
>>>Now that VEC_COND_EXPR has normal unnested operands,
>>>operation_could_trap_p can treat it like any
Richard Biener writes:
> On April 27, 2021 5:12:35 PM GMT+02:00, Richard Sandiford
> wrote:
>>Now that VEC_COND_EXPR has normal unnested operands,
>>operation_could_trap_p can treat it like any other expression.
>>
>>This fixes many testsuite ICEs for SVE, but i
On April 27, 2021 5:12:35 PM GMT+02:00, Richard Sandiford
wrote:
>Now that VEC_COND_EXPR has normal unnested operands,
>operation_could_trap_p can treat it like any other expression.
>
>This fixes many testsuite ICEs for SVE, but it turns out that none
>of the tests in gcc.tar
Now that VEC_COND_EXPR has normal unnested operands,
operation_could_trap_p can treat it like any other expression.
This fixes many testsuite ICEs for SVE, but it turns out that none
of the tests in gcc.target/aarch64/sve were affected. Anyone testing
on non-SVE aarch64 therefore wouldn't
This removes now unnecessary special-casings of VEC_COND_EXPRs after
making its first operand a gimple value.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-04-14 Richard Biener
* genmatch.c (lower_cond): Remove VEC_COND_EXPR special-casing.
(capture_info
This adjusts GIMPLE verification with respect to the VEC_COND_EXPR
changes forcing a split out condition.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-04-14 Richard Biener
* tree-cfg.c (verify_gimple_assign_ternary): Verify that
VEC_COND_EXPRs have a
This fixes the condition to match the comment and only lower
VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPRs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-11-26 Richard Biener
* gimple-isel.c (gimple_expand_vec_cond_expr): Only
lower VECTOR_BOOLEAN_TYPE_P VEC_COND_EX
This fixes a mistake in the optab query done by ISEL. It
doesn't fix the PR but shifts the ICE elsewhere.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-11-03 Richard Biener
PR middle-end/97579
* gimple-isel.cc (gimple_expand_vec_cond_expr): Use
. So the compensation
> >> needs to happen in ISEL, recognizing
> >>
> >> _1 = {0}
> >> _2 = _1 ? ...;
> >>
> >> as
> >>
> >> _2 = .VCOND (0 == 0, ...)
> >
> > Do we really want to do a scalar arguments of .VC
ts allow bitwise arithmetic on them...). So the compensation
needs to happen in ISEL, recognizing
_1 = {0}
_2 = _1 ? ...;
as
_2 = .VCOND (0 == 0, ...)
Do we really want to do a scalar arguments of .VCOND? Note that in PR96453
(a similar bug), we end up with:
_5 = { -1, -1 };
_6
pen in ISEL, recognizing
_1 = {0}
_2 = _1 ? ...;
as
_2 = .VCOND (0 == 0, ...)
Do we really want to do a scalar arguments of .VCOND? Note that in PR96453
(a similar bug), we end up with:
_5 = { -1, -1 };
_6 = VEC_COND_EXPR <_5, { -1, -1 }, { 0, 0 }>;
Thanks for hints,
Martin
*)(tree));
> diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
> index b330cf4c20e..32e3bc31f7f 100644
> --- a/gcc/gimple-isel.cc
> +++ b/gcc/gimple-isel.cc
> @@ -33,8 +33,8 @@ along with GCC; see the file COPYING3. If not see
> #include "gimplify-me.h"
> #i
quot;gimplify-me.h"
#include "gimplify.h"
#include "tree-cfg.h"
-#include "bitmap.h"
#include "tree-ssa-dce.h"
+#include "gimple-fold.h"
/* Expand all VEC_COND_EXPR gimple assignments into calls to internal
pes, that we can operate on, not be forced to appear only as the first
> >>>> argument of a vcond.
> >>>>
> >>>> I can think of 2 natural ways to improve things: either implement vector
> >>>> comparisons in the ARM backend (possibly b
be someone who
knows arm could copy the relevant code over?
Does my message make sense, do people have comments?
So what complicates things now (and to some extent pre-existed when you
used AVX512 which _could_ operate on boolean vectors) is that we
have split out the condition from VEC_COND_EXPR t
implement vector
> >> comparisons in the ARM backend (possibly by forwarding to their existing
> >> code for vcond), or in the generic expansion code try using vcond if the
> >> direct comparison opcode is not provided.
> >>
> >> We can temporarily revert my
eople have comments?
So what complicates things now (and to some extent pre-existed when you
used AVX512 which _could_ operate on boolean vectors) is that we
have split out the condition from VEC_COND_EXPR to separate stmts
but we do not expect backends to be able to code-generate the separate
form - in
gt; We can temporarily revert my patch, but I would like it to be temporary.
> Since aarch64 seems to handle the same code just fine, maybe someone who
> knows arm could copy the relevant code over?
>
> Does my message make sense, do people have comments?
So what complicates things no
On Thu, 6 Aug 2020, Christophe Lyon wrote:
Was I on the right track configuring with
--target=arm-none-linux-gnueabihf --with-cpu=cortex-a9
--with-fpu=neon-fp16
then compiling without any special option?
Maybe you also need --with-float=hard, I don't remember if it's
implied by the 'hf' target
On Thu, 6 Aug 2020 at 13:42, Marc Glisse wrote:
>
> On Thu, 6 Aug 2020, Christophe Lyon wrote:
>
> > On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote:
> >>
> >> On Thu, 6 Aug 2020, Christophe Lyon wrote:
> >>
> > 2020-08-05 Marc Glisse
> >
> > PR tree-optimization/95906
> >>>
On Thu, 6 Aug 2020, Christophe Lyon wrote:
On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote:
On Thu, 6 Aug 2020, Christophe Lyon wrote:
2020-08-05 Marc Glisse
PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote:
>
> On Thu, 6 Aug 2020, Christophe Lyon wrote:
>
> >>> 2020-08-05 Marc Glisse
> >>>
> >>> PR tree-optimization/95906
> >>> PR target/70314
> >>> * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
> >>> (v ? w
vector comparisons were forced to use vec_cond_expr, we lost a number of
optimizations (my fault for not adding enough testcases to prevent that).
This patch tries to unwrap vec_cond_expr a bit so some optimizations can
still happen.
I wasn't planning to add all those transformations together
egtest during the night.
> > >
> > > When vector comparisons were forced to use vec_cond_expr, we lost a
> > > number of
> > > optimizations (my fault for not adding enough testcases to prevent that).
> > > This patch tries to unwrap vec_cond_expr a bit
On Thu, 6 Aug 2020, Christophe Lyon wrote:
2020-08-05 Marc Glisse
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)): Upd
Hi,
On Wed, 5 Aug 2020 at 16:24, Richard Biener via Gcc-patches
wrote:
>
> On Wed, Aug 5, 2020 at 3:33 PM Marc Glisse wrote:
> >
> > New version that passed bootstrap+regtest during the night.
> >
> > When vector comparisons were forced to use vec_cond_
On Wed, Aug 5, 2020 at 3:33 PM Marc Glisse wrote:
>
> New version that passed bootstrap+regtest during the night.
>
> When vector comparisons were forced to use vec_cond_expr, we lost a number of
> optimizations (my fault for not adding enough testcases to prevent that).
> T
New version that passed bootstrap+regtest during the night.
When vector comparisons were forced to use vec_cond_expr, we lost a number of
optimizations (my fault for not adding enough testcases to prevent that).
This patch tries to unwrap vec_cond_expr a bit so some optimizations can
still
-ftrapping-math does not disable folding of
typedef double vecf __attribute__((vector_size(16)));
typedef long long veci __attribute__((vector_size(16)));
vecf f(veci c){
vecf z={};
return (z+1)/(z+3);
}
despite a possible inexact flag, so it doesn't disable vec_cond_expr
folding eithe
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse writes:
+/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
+ (simplify
+ (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
+ (with
+ {
+ tree rhs1
> I thought match.pd applied to things like FP addition as normal and
> it was up to individual patterns to check the appropriate properties.
I think it can be indeed defered to the simplification of (op @0 @2)
because that would be invalid if it removes a IEEE exception.
The VEC_COND_EXPR itself cannot trap.
Richard.
> Thanks,
> Richard
Marc Glisse writes:
> On Fri, 31 Jul 2020, Richard Sandiford wrote:
>
>> Marc Glisse writes:
>>> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
>>> + (simplify
>>> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
>>> + (with
>>> + {
>>> + tree rhs1, rhs2 = NULL;
>>> +
On Fri, 31 Jul 2020, Richard Biener wrote:
On Fri, Jul 31, 2020 at 1:39 PM Richard Biener
wrote:
On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
wrote:
On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
When vector comparisons were forced to use vec_cond_expr, we lost a number
of
gt; > >
> > > > When vector comparisons were forced to use vec_cond_expr, we lost a
> > > > number
> > > > of optimizations (my fault for not adding enough testcases to prevent
> > > > that). This patch tries to unwrap vec_cond_expr
On Fri, 31 Jul 2020, Richard Biener wrote:
+/* (v ? w : 0) ? a : b is just (v & w) ? a : b */
+(simplify
+ (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2)
+ (vec_cond (bit_and @0 @3) @1 @2))
Does something check automatically that @0 and @3 have compatible types?
@0 should always have a v
On Fri, Jul 31, 2020 at 1:39 PM Richard Biener
wrote:
>
> On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
> wrote:
> >
> > On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
> > >
> > > When vector comparisons were forced to use vec_cond_expr, we lost a
n @0 producing a regular V4SImode vector mask for an outer
AVX512 SSE-style vec-cond and you then would get a mismatch.
So indeed better add a type compatibility check.
> My memory of this dates from before the avx512-related changes, but at
> least at the time, the type of the condition in v
On Fri, Jul 31, 2020 at 1:35 PM Richard Biener
wrote:
>
> On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
> >
> > When vector comparisons were forced to use vec_cond_expr, we lost a number
> > of optimizations (my fault for not adding enough testcases to prevent
> &
from before the avx512-related changes, but at
least at the time, the type of the condition in vec_cond_expr had to have
the same size and number of elements as the result, and have signed
integral elements. Now the size constraint has changed, but it still looks
like for a given number of eleme
On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote:
>
> When vector comparisons were forced to use vec_cond_expr, we lost a number
> of optimizations (my fault for not adding enough testcases to prevent
> that). This patch tries to unwrap vec_cond_expr a bit so some
> optimiza
Marc Glisse writes:
> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
> + (simplify
> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
> + (with
> + {
> + tree rhs1, rhs2 = NULL;
> + rhs1 = fold_binary (op, type, @1, @3);
> + if (rhs1 && is_gimple_val (rhs1))
> +
When vector comparisons were forced to use vec_cond_expr, we lost a number
of optimizations (my fault for not adding enough testcases to prevent
that). This patch tries to unwrap vec_cond_expr a bit so some
optimizations can still happen.
I wasn't planning to add all those transforma
and_vector_condition for each VEC_COND_EXPR use,
> > making that return whether it "consumed" the comparison. If all uses
> > consumed the comparison we should DCE it, if not, we should lower it?
>
> All right, I prepared patch for it.
>
> Patch can bootstrap on x86
On 6/30/20 3:03 PM, Richard Biener wrote:
Now to simply restore previous behavior for this particular case we should
probably make expand_vector_comparison walk immediate uses as you do
but then call expand_vector_condition for each VEC_COND_EXPR use,
making that return whether it "consumed
On Tue, Jun 30, 2020 at 2:16 PM Martin Liška wrote:
>
> On 6/30/20 12:38 PM, Richard Biener wrote:
> > On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about blocking of vector expansion of comparisons
>
On 6/30/20 12:38 PM, Richard Biener wrote:
On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
Hi.
The patch is about blocking of vector expansion of comparisons
that are only feeding a VEC_COND_EXPR statements.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
The
On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about blocking of vector expansion of comparisons
> that are only feeding a VEC_COND_EXPR statements.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> The problemati
Hi.
The patch is about blocking of vector expansion of comparisons
that are only feeding a VEC_COND_EXPR statements.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
The problematic mips64 test-case looks good now.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog
You can simplify the patch by eliding the num_imm_uses checks
Really? How can I be sure that a SSA_NAME is not shared among different
VEC_COND_EXPR statements (or even by some other statements)?
The bitmap DCE does this check for you.
and by using auto_bitmap.
Oh yeah!
Why is it ne
ng debug stmts and thus eventually allocating debug decls.
> >>
> >> Sure, done in the updated patch.
> >
> > You can simplify the patch by eliding the num_imm_uses checks
>
> Really? How can I be sure that a SSA_NAME is not shared among different
> VEC_COND_EXPR sta
a SSA_NAME is not shared among different
VEC_COND_EXPR statements (or even by some other statements)?
and by using auto_bitmap.
Oh yeah!
Why is it necessary to update
the veclower pass btw? Is that just to avoid useless isels
on dead code?
Yes:
_10 = _9 != { 0, 0, 0, 0 };
_11 = *a_16
On Wed, Jun 24, 2020 at 10:49 AM Martin Liška wrote:
>
> On 6/24/20 9:43 AM, Richard Biener wrote:
> > Hmm, can you instead use simple_dce_from_worklist and simply
> > record all SSA_NAMEs you end up "forwarding" as possibly dead
> > in a bitmap? At least that hashmap traversal looks dangerous
>
n Liska
Date: Wed, 24 Jun 2020 08:08:00 +0200
Subject: [PATCH] VEC_COND_EXPR: clean up first argument
gcc/ChangeLog:
PR tree-optimization/95745
PR middle-end/95830
* gimple-isel.cc (gimple_expand_vec_cond_exprs): Delete dead
SSA_NAMEs used as the first argument of a VEC_COND_EXPR. Alw
On Wed, Jun 24, 2020 at 9:21 AM Martin Liška wrote:
>
> Hi.
>
> When expanding a VEC_COND_EXPR it happens that first argument (a SSA_NAME)
> that can be no longer used. When that happens we need to remove the SSA_NAME,
> otherwise we end up expanding it and for targets like
Hi.
When expanding a VEC_COND_EXPR it happens that first argument (a SSA_NAME)
that can be no longer used. When that happens we need to remove the SSA_NAME,
otherwise we end up expanding it and for targets like s390x, there's no optab
expansion. We need to remove them at both places as -O0
00
> Subject: [PATCH] rs6000: fix creation of VEC_COND_EXPR
Capital F on Fix. Easy check is to run "git log --oneline" and see
if your commit seems out of place ;-)
> * config/rs6000/rs6000-call.c (fold_build_vec_cmp):
> Since 502d63b6d6141597bb18fd23c8773
5.0e+0 };
__asm__ __volatile__("" : : : "memory");
vect__1.13_51 = MEM [(double *)&s1 + 8B];
vect__2.16_55 = MEM [(double *)&s2 + 8B];
- vect_iftmp.17_58 = VEC_COND_EXPR ;
- MEM [(double *)&s3 + 8B] = vect_iftmp.17_58;
+ _58 = vect__1.13_51 u<=
:
On Mon, Jun 15, 2020 at 1:19 PM Martin Liška wrote:
On 6/15/20 9:14 AM, Richard Biener wrote:
On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
On 6/12/20 11:43 AM, Richard Biener wrote:
So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely
On Thu, Jun 18, 2020 at 10:21 AM Martin Liška wrote:
>
> On 6/18/20 10:00 AM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> >> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
> On 6/15/20 1:59 PM, Richard Biener wrote:
> >>>> On Mon, Jun 15, 2020 at 1:19 PM Martin Liška wrote:
> >>>>>
> >>>>> On 6/15/20 9:14 AM, Richard Biener wrote:
> >>>>>> On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
&
On 6/18/20 10:00 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
first
argument to be a SSA_NAME (or constant) and so the patch fixes that.
What does this mean? All
:
On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
On 6/12/20 11:43 AM, Richard Biener wrote:
So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?
Apparently, I'm quite close. Using the attached patch I see o
Hi!
On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
> first
> argument to be a SSA_NAME (or constant) and so the patch fixes that.
What does this mean? All context is missing here.
Also, is
Hi.
This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects first
argument to be a SSA_NAME (or constant) and so the patch fixes that.
Using the patch, I survive powerpc.exp test-suite.
Ready for master?
Martin
gcc/ChangeLog:
* config/rs6000/rs6000-call.c
9:14 AM, Richard Biener wrote:
> > >>> On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
> > >>>>
> > >>>> On 6/12/20 11:43 AM, Richard Biener wrote:
> > >>>>> So ... how far are you with enforcing a split VEC_COND_EXPR?
ška wrote:
> >>>>
> >>>> On 6/12/20 11:43 AM, Richard Biener wrote:
> >>>>> So ... how far are you with enforcing a split VEC_COND_EXPR?
> >>>>> Thus can we avoid the above completely (even as intermediate
> >>>>&
VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?
Apparently, I'm quite close. Using the attached patch I see only 2 testsuite
failures:
FAIL: gcc.dg/tree-ssa/pr68714.c scan-tree-dump-times reassoc1 " <= " 1
FAIL: gcc.target/i386/pr78102.c scan-assembl
On Mon, Jun 15, 2020 at 1:19 PM Martin Liška wrote:
>
> On 6/15/20 9:14 AM, Richard Biener wrote:
> > On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
> >>
> >> On 6/12/20 11:43 AM, Richard Biener wrote:
> >>> So ... how far are you with enforcin
On 6/15/20 9:14 AM, Richard Biener wrote:
On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
On 6/12/20 11:43 AM, Richard Biener wrote:
So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?
Apparently, I'm
On Fri, Jun 12, 2020 at 3:24 PM Martin Liška wrote:
>
> On 6/12/20 11:43 AM, Richard Biener wrote:
> > So ... how far are you with enforcing a split VEC_COND_EXPR?
> > Thus can we avoid the above completely (even as intermediate
> > state)?
>
> Apparently, I
On 6/12/20 11:43 AM, Richard Biener wrote:
So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?
Apparently, I'm quite close. Using the attached patch I see only 2 testsuite
failures:
FAIL: gcc.dg/tree-ssa/pr68
r_size(16)));
v2df foo (v2df a, v2df b, v2df c, v2df d)
{
v2df res;
try
{
res = a < b ? c : d;
return res; // replace with gcc_unreachable () for more twists
}
catch (...)
{
return res;
}
}
So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid
>From fc5a59e8c8887c102bff06e1a537ccfc9d44e3d8 Mon Sep 17 00:00:00 2001
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
t
On 6/10/20 2:27 PM, Martin Liška wrote:
/home/marxin/Programming/testcases/vect-low.c: In function ‘v2df foo(v2df,
v2df, v2df, v2df)’:
/home/marxin/Programming/testcases/vect-low.c:3:6: error: BB 2 is missing an EH
edge
Ok, I was missing copying of the EH edges:
FOR_EACH_EDGE (e, ei, g
= VEC_COND_EXPR ;
[local count: 1073741824]:
# _2 = PHI <{ 0.0, 0.0 }(4), _8(2)>
return _2;
[count: 0]:
: [LP 1]
_1 = __builtin_eh_pointer (1);
__cxa_begin_catch (_1);
__cxa_end_catch ();
goto ; [0.00%]
I tried to use:
maybe_clean_or_replace_eh_stmt (stmt, assign);
whic
OPTAB_CAN_FAIL which is no longer
> > there.
>
>
> Sure.
>
> >
> > Can you put the isel pass to a separate file please?
>
> Yes.
>
> >
> > So this is a first step towards sanitizing VEC_COND_EXPR. There were
> > followups
> > mentioned,
linux-gnu.
Ready to be installed?
The ChangeLog refers to DEF_INTERNAL_OPTAB_CAN_FAIL which is no longer there.
Sure.
Can you put the isel pass to a separate file please?
Yes.
So this is a first step towards sanitizing VEC_COND_EXPR. There were followups
mentioned, namely a) enforcing
nu.
>
> Ready to be installed?
The ChangeLog refers to DEF_INTERNAL_OPTAB_CAN_FAIL which is no longer there.
Can you put the isel pass to a separate file please?
So this is a first step towards sanitizing VEC_COND_EXPR. There were followups
mentioned, namely a) enforcing that VEC_COND_
a070 Mon Sep 17 00:00:00 2001
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): Likew
On Wed, Jun 03, 2020 at 02:09:11PM -0500, Segher Boessenkool wrote:
> Yeah, but that is specific to the vectoriser, not something that the
> RTL expander should have to deal with. A big impedance mismatch there.
It isn't specific to vectorizer, many named patterns aren't allowed to FAIL
and many
On Wed, Jun 03, 2020 at 08:38:04PM +0200, Richard Biener wrote:
> On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
> >> >> mask = vec_cmp of the comparison
> >> >> true_masked = true_op & mask;
> >> >> false
On Wed, Jun 3, 2020 at 2:38 PM Richard Biener
wrote:
>
> On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
> >> >> mask = vec_cmp of the comparison
> >> >> true_masked = true_op & mask;
> >> >> false_masked
On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool
wrote:
>On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
>> >> mask = vec_cmp of the comparison
>> >> true_masked = true_op & mask;
>> >> false_masked = false_op & ~mask;
>> >> result = true_masked | false_masked;
>>
1 - 100 of 251 matches
Mail list logo
