Hi All,
This patch adds support for a compact syntax for specifying constraints in
instruction patterns. Credit for the idea goes to Richard Earnshaw.
With this new syntax we want a clean break from the current limitations to make
something that is hopefully easier to use and maintain.
The idea
Hi,
Thanks for the review, just some quick responses before I make the changes:
> >int operand_number; /* Operand index in the big array. */
> >int output_format; /* INSN_OUTPUT_FORMAT_*. */
> > + bool compact_syntax_p;
> >struct operand_data operand[MAX_
Hi,
New version of the patch, I've omitted the explanation again 😊
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Thanks,
Tamar
gcc/ChangeLog:
* gensupport.cc (class conlist, add_constraints, add_attributes,
create_missing_attributes, skip_spaces
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches): Add nosimd.
(*mov_aarch64, *movsi_aarch64, *movdi_aarch6
Hi Coudert,
Sorry, missed that one.
I'll fix that.
Tamar.
> -Original Message-
> From: FX Coudert
> Sent: Saturday, June 10, 2023 9:21 PM
> To: Tamar Christina
> Cc: g...@gcc.gnu.org; Jeff Law ; gcc-
> patc...@gcc.gnu.org
> Subject: gcc/config.in was not regenerated
>
> Hi,
>
> Buil
Hi All,
Looks like I forgot to regenerate config.in which
causes updates when you enable maintainer mode.
Bootstrapped aarch64-none-linux-gnu.
Committed under obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
* config.in: Regenerate.
--- inline copy of patch --
diff --git a/gcc/config.in b
>
> Do you use the DEFAULT_MATCHPD_PARTITIONS macro anywhere?
> If not, why the AC_DEFINE_UNQUOTED at all and not just the AC_SUBST?
>
It used to be used to change the default of genmatch.cc, but the default is now
not to split anymore. So guess I can remove it.
Will follow up...
Hi All,
As Jakub pointed out, DEFAULT_MATCHPD_PARTITIONS
is now unused and can be removed.
Bootstrapped aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove DEFAULT_MA
Hi All,
Updated patch with feedback addressed.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Thanks,
Tamar
gcc/ChangeLog:
* gensupport.cc (class conlist, add_constraints, add_attributes,
skip_spaces, expect_char, preprocess_compact_syntax,
> e7ac2b5f3db55de3dbbab7bd2bfe08388f4ec533..cab82d7960e5be517bba2
> 621f7f4
> > 888e7bf3c295 100644
> > --- a/gcc/cfgloop.h
> > +++ b/gcc/cfgloop.h
> > @@ -272,6 +272,14 @@ public:
> > the basic-block from being collected but its index can still be
> > reused. */
> >basic_block for
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 13, 2023 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 8/19]middle-end: updated niters analysis to handle
> multiple exits.
>
> On Wed, 28 Jun 2023, Tamar C
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 13, 2023 6:31 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 12/19]middle-end: implement loop peeling and IV
> updates for early break.
>
> On Wed, 28 Jun 2023, Ta
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 17, 2023 7:19 AM
> To: Roger Sayle
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH] Fix bootstrap failure (with g++ 4.8.5) in
> tree-if-conv.cc.
>
> On Fri, Jul 14, 2023 at 8:56 PM Roger Sayle
> wrot
> On Mon, Jul 17, 2023 at 12:21 AM Tamar Christina via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Monday, July 17, 2023 7:19 AM
> > > To: Roger Sayle
> > > Cc: gcc-
> -Original Message-
> From: Richard Biener
> Sent: Friday, July 14, 2023 2:35 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 12/19]middle-end: implement loop peeling and IV
> updates for early break.
>
> On Thu, 13 Jul 2023, Ta
I think Andrew is listed as maintainer for tree-ssa, or maybe it's on one of
the Richard's lists?
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Philipp
> Tomsich
> Sent: Tuesday, July 11, 2023 7:51 AM
> To: Jakub Jelinek
> Cc: gcc-pat
Hi All,
The resulting predicate register of a whilelo is not
restricted to the lower half of the predicate register file.
As such these tests started failing after recent changes
because the whilelo outside the loop is getting assigned p15.
This widens the regexp.
Tested on aarch64-none-linux-g
Hi All,
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should
not be applied to a particular loop.
ICC/ICX also has such a pragma for C and C++ called #pragma novector.
As part of this patch series I need a way to easily turn off vectorization of
particular loops, part
Hi All,
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should
not be applied to a particular loop.
ICC/ICX also has such a pragma for C and C++ called #pragma novector.
As part of this patch series I need a way to easily turn off vectorization of
particular loops, part
> > +
> > + cp_token *tok = pragma_tok;
> > +
> > + do
> > {
> > - tok = cp_lexer_consume_token (parser->lexer);
> > - ivdep = cp_parser_pragma_ivdep (parser, tok);
> > - tok = cp_lexer_peek_token (the_parser->lexer);
> > + switch (cp_parser_pragma_kind (tok))
> >
Hi, This is a respin of the patch taking in the feedback received from the C++
part.
Simultaneously it's also a ping 😊
Hi All,
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should
not be applied to a particular loop.
ICC/ICX also has such a pragma for C and C+
Ping.
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, July 26, 2023 8:35 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; jos...@codesourcery.com
> Subject: RE: [PATCH 2/2][frontend]: Add novector C pragma
>
> Hi, This is a respin of the patch taking in the f
Hi All,
When determining issue rates we currently discount non-constant MLA accumulators
for Advanced SIMD but don't do it for the latency.
This means the costs for Advanced SIMD with a constant accumulator are wrong and
results in us costing SVE and Advanced SIMD the same. This can cauze us to
Hi All,
boolean comparisons have different cost depending on the mode. e.g.
a && b when predicated doesn't require an addition instruction, the AND is free
by combining the predicate of the one operation into the second one. At the
moment though we only fuse compares so this update requires one o
Hi All,
In GCC 11 we implemented the vectorizer optab for widening left shifts,
however this optab is only supported for uniform shift constants.
At the moment GCC still has two loop vectorization strategy (classical loop and
SLP based loop vec) and the optab is implemented as a scalar pattern.
Hi All,
Currently we segfault when len == 0 for an attribute list.
essentially [cons: =0, 1, 2, 3; attrs: ] segfaults but should be equivalent to
[cons: =0, 1, 2, 3] and [cons: =0, 1, 2, 3; attrs:]. This fixes it by just
returning early and leaving it to the validators whether this should error
> Tamar Christina writes:
> > Hi All,
> >
> > When determining issue rates we currently discount non-constant MLA
> > accumulators for Advanced SIMD but don't do it for the latency.
> >
> > This means the costs for Advanced SIMD with a constant accumulator are
> > wrong and results in us costing S
Hi All,
My previous patch can cause a problem if the pattern matches after veclower
as it may replace the construct with a vector sequence which the target may not
directly support.
As such don't perform the rewriting if after veclower.
Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc
> > so that the multiple_p test is skipped if the structure is undefined.
>
> Actually, we should probably skip the constant_multiple_p test as well.
> Keeping it would only be meaningful for little-endian.
>
> simplify_gen_subreg should alread do the necessary checks to make sure
> that the subr
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 20, 2022 9:57 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end simplify complex if expressions where
> comparisons are inverse of one another.
>
> On Thu, 16 Jun 2022, Tamar Chr
> > }
> > + else if (EDGE_SUCC (bb1, 0)->dest == EDGE_SUCC (bb2, 0)->dest
> > + && single_succ_p (bb1)
> > + && single_succ_p (bb2)
> > + && single_pred_p (bb1)
> > + && single_pred_p (bb2)
> > + && single_succ_p (EDGE_SUCC (bb1, 0)->dest))
>
>
one another.
>
> On Tue, Jul 5, 2022 at 8:16 AM Tamar Christina via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Monday, June 20, 2022 9:57 AM
> > > To: Tamar
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 7, 2022 8:19 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: don't lower past veclower [PR106063]
>
> On Tue, 5 Jul 2022, Tamar Christina wrote:
>
> > Hi All,
> >
> > My prev
gcc-
> > > patc...@gcc.gnu.org
> > > Subject: Re: [PATCH]middle-end simplify complex if expressions where
> > > comparisons are inverse of one another.
> > >
> > > On Tue, Jul 5, 2022 at 8:16 AM Tamar Christina via Gcc-patches > > patc...@gcc.gnu.o
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 7, 2022 8:47 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH]middle-end: don't lower past veclower [PR106063]
>
> On Thu, 7 Jul 2022, Tamar Christina wrote:
>
> > > -Original Message
Hi All,
I seem to have broken the s390 bootstrap because I added a new parameter to the
store_bit_field function to indicate whether the value the field of is being set
is currently undefined.
If it's undefined we use a subreg instead. In this case the value of false
restores the old behavior.
ping
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, July 5, 2022 4:26 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
> max/min.
>
> > > }
> > > + else if (EDGE_SUCC
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, July 12, 2022 2:19 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
> max/min.
>
> On Tue, 5 Jul 2022, Tamar Christina wrote:
>
> > > > When this function replaces the edge it doesn't seem to update the
> > > dominators.
> > > > Since It's replacing the middle BB we then end up with an error
> > > >
> > > > gcc/testsuite/gcc.dg/tree-ssa/minmax-14.c:17:1: error: dominator
> > > > of 5 should be 4, not 2
> > > >
> > > > durin
>
> On Tue, Aug 2, 2022 at 10:33 AM Tamar Christina via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> > > > > > When this function replaces the edge it doesn't seem to update
> > > > > > the
> > > > > domi
c-patches
> > > Cc: Tamar Christina ; Richard Biener
> > > ; Richard Guenther
> ;
> > > nd
> > > Subject: Re: [PATCH 1/2]middle-end: Simplify subtract where both
> > > arguments are being bitwise inverted.
> > >
> > > Richard
Hi All,
The failures on -m32 on x86 show that the checks at the top level in
tree_ssa_phiopt_worker aren't enough for diamond_p.
In minmax_replacement we perform the additional validation of the shape but by
then it's too late to catch these case.
This patch changes it so we check that for a dia
Hi All,
This excludes value_replacement and store_elim from diamonds as they don't
handle the form properly.
Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR middle-end/106534
* tree-ssa-phiopt.
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Tuesday, July 12, 2022 2:46 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH 1/2]AArch64 Fix 128-bit sequential consistency atomic
> operatio
> > +
> > +(define_constraint "D3"
> > + "@internal
> > + A constraint that matches vector of immediates that is with 0 to
> > +(bits(mode)/2)-1."
> > + (and (match_code "const,const_vector")
> > + (match_test "aarch64_const_vec_all_same_in_range_p (op, 0,
> > + (GET_MODE_UN
> >> Do you see vect_constant_defs in practice, or is this just for
> >> completeness?
> >> I would expect any constants to appear as direct operands. I don't
> >> mind keeping it if it's just a belt-and-braces thing though.
> >
> > In the latency case where I had allow_constants the early reject
> > Yeah if you comment it out one of the testcases should fail.
>
> using new_preheader instead of e->dest would make things clearer.
>
> You are now adding the same arg to every exit (you've just queried the
> main exit redirect_edge_var_map_vector).
>
> OK, so I think I understand what you're
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 18, 2023 2:53 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 12/19]middle-end: implement loop peeling and IV
> updates for early break.
>
> On Fri, 18 Aug 2023, Ta
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 19, 2023 7:28 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] Remove -save-temps from tests using -flto
>
> The following removes -save-temps that doesn't seem to have any good
> reason from tests
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 19, 2023 11:19 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Remove -save-temps from tests using -flto
>
> On Mon, 19 Jun 2023, Tamar Christina wrote:
>
> > > -Original Message-
> >
> -Original Message-
> From: Jeff Law
> Sent: Tuesday, June 20, 2023 3:17 AM
> To: Andrew Pinski ; Thiago Jung Bauermann
>
> Cc: Manolis Tsamis ; Philipp Tomsich
> ; Richard Biener ;
> Palmer Dabbelt ; Kito Cheng ;
> gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH 2/2] cpr
Hi All,
I accidentally left a test comment in the final version of the patch.
This removes the comment.
Regtested on aarch64-none-linux-gnu and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64.md (*mov_aarch64): Drop test comment.
---
Hi All,
define_cond_exec does not support the special @@ syntax
and so can't support {@. As such just remove support
for it.
Bootstrapped and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR bootstrap/110324
* gensupport.cc (convert_syntax): Explicitly check for RTX
Hi All,
It seems like @blackslashchar{} is a relatively new addition
to texinfo. Other parts of the docs use @samp{\} so use it
here too so older distros work.
Bootstrapped on aarch64-none-linux-gnu and no issues.
committed under obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
PR other/11
Hi All,
This patch adds initial support for early break vectorization in GCC.
The support is added for any target that implements a vector cbranch optab,
this includes both fully masked and non-masked targets.
Depending on the operation, the vectorizer may also require support for boolean
mask re
Hi,
With the patch enabling the vectorization of early-breaks, we'd like to allow
bitfield lowering in such loops, which requires the relaxation of allowing
multiple exits when doing so. In order to avoid a similar issue to PR107275,
the code that rejects loops with certain types of gimple_stmts
Hi All,
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should
not be applied to a particular loop.
ICC/ICX also has such a pragma for C and C++ called #pragma novector.
As part of this patch series I need a way to easily turn off vectorization of
particular loops, part
Hi All,
There's an existing bug in loop frequency scaling where the if statement checks
to see if there's a single exit, and records an dump file note but then
continues.
It then tries to access the null pointer, which of course fails.
For multiple loop exists it's not really clear how to scale
Hi All,
The bitfield vectorization support does not currently recognize bitfields inside
gconds. This means they can't be used as conditions for early break
vectorization which is a functionality we require.
This adds support for them by explicitly matching and handling gcond as a
source.
Testca
Hi All,
expand_vector_piecewise does not support VLA expansion as it has a hard assert
on the type not being VLA.
Instead of just failing to expand and so the call marked unsupported we ICE.
This adjust it so we don't and can gracefully handle the expansion in support
checks.
Bootstrapped Regtes
Hi All,
This patch splits off the vectorizer's understanding of the main loop exit off
from the normal loop infrastructure.
Essentially we're relaxing the use of single_exit() in the vectorizer as we will
no longer have a single single and need a well defined split between the main
and secondary
Hi All,
For early break vectorization we have to update niters analysis to record and
analyze all exits of the loop, and so all conds.
The niters of the loop is still determined by the main/natural exit of the loop
as this is the O(n) bounds. For now we don't do much with the secondary conds,
bu
Hi All,
Vectorization of a gcond starts off essentially the same as vectorizing a
comparison witht he only difference being how the operands are extracted.
This refactors vectorable_comparison such that we now have a generic function
that can be used from vectorizable_early_break. The refactorin
Hi All,
When performing early break vectorization we need to be sure that the vector
operations are safe to perform. A simple example is e.g.
for (int i = 0; i < N; i++)
{
vect_b[i] = x + i;
if (vect_a[i]*2 != x)
break;
vect_a[i] = x;
}
where the store to vect_b is not allowed
Hi All,
This implements vectorable_early_exit which is used as the codegen part of
vectorizing a gcond.
For the most part it shares the majority of the code with
vectorizable_comparison with addition that it needs to be able to reduce
multiple resulting statements into a single one for use in the
Hi All,
This patch updates the peeling code to maintain LCSSA during peeling.
The rewrite also naturally takes into account multiple exits and so it didn't
make sense to split them off.
For the purposes of peeling the only change for multiple exits is that the
secondary exits are all wired to the
Hi All,
I didn't want these to get lost in the noise of updates.
The following three tests now correctly work for targets that have an
implementation of cbranch for vectors so XFAILs are conditionally removed gated
on vect_early_break support.
Bootstrapped Regtested on aarch64-none-linux-gnu and
Hi All,
Advanced SIMD lacks flag setting vector comparisons which SVE adds. Since
machines
with SVE also support Advanced SIMD we can use the SVE comparisons to perform
the
operation in cases where SVE codegen is allowed, but the vectorizer has decided
to generate Advanced SIMD because of loop
Hi All,
This adds an implementation for conditional branch optab for MVE.
Unfortunately MVE has rather limited operations on VPT.P0, we are missing the
ability to do P0 comparisons and logical OR on P0.
For that reason we can only support cbranch with 0, as for comparing to a 0
predicate we don'
Hi All,
This adds an implementation for conditional branch optab for AArch32.
For e.g.
void f1 ()
{
for (int i = 0; i < N; i++)
{
b[i] += a[i];
if (a[i] > 0)
break;
}
}
For 128-bit vectors we generate:
vcgt.s32q8, q9, #0
vpmax.u32 d7,
Hi All,
This adds an implementation for conditional branch optab for AArch64.
For e.g.
void f1 ()
{
for (int i = 0; i < N; i++)
{
b[i] += a[i];
if (a[i] > 0)
break;
}
}
For 128-bit vectors we generate:
cmgtv1.4s, v1.4s, #0
umaxp v1.4s, v1.4s,
Hi All,
Advanced SIMD lacks a cmpeq for vectors, and unlike compare to 0 we can't
rewrite to a cmtst.
This operation is however fairly common, especially now that we support early
break vectorization.
As such this adds a pattern to recognize the negated any comparison and
transform it to an all.
Resending attached only due to size limit
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, June 28, 2023 2:42 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: [PATCH 3/19]middle-end clean up vect testsuite using pragma
> novecto
Adding proper maintainers.
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, June 28, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
>
> Subject: [PATCH 9/19]AArch64 middle-end: refactor vec
gets the more bugs I can fix 😊
Cheers,
Tamar
> Thanks.
>
>
> juzhe.zh...@rivai.ai
>
> From: Li, Pan2
> Date: 2023-06-28 22:21
> To: juzhe.zh...@rivai.ai
> Subject: FW: [PATCH v5 0/19] Support early break/return auto-vectorization
> FYI.
>
> -Original Message-
Hi Jason,
Thanks for the review. I only now realized I should have split them between C
and C++.
Will do so on the respins.
>
> On 6/28/23 09:41, Tamar Christina wrote:
> > Hi All,
> >
> > FORTRAN currently has a pragma NOVECTOR for indicating that
> > vectorization should not be applied to a
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > expand_vector_piecewise does not support VLA expansion as it has a
> > hard assert on the type not being VLA.
> >
> > Instead of just failing to expand and so the call marked unsupported we ICE.
> > This adjust it so we don't and
Hi All,
Following on from Jakub's patch in g:de0ee9d14165eebb3d31c84e98260c05c3b33acb
these two patches finishes the work fixing the regression and improves codegen.
As explained in that commit, ifconvert sorts PHI args in increasing number of
occurrences in order to reduce the number of comparis
Hi All,
This patch builds on the previous patch by fixing another issue with the
way ifcvt currently picks which branches to test.
The issue with the current implementation is while it sorts for
occurrences of the argument, it doesn't check for complexity of the arguments.
As an example:
[lo
Hi Both,
Thanks for all the reviews/patches so far 😊
> >
> > Looks good, but I wonder what we can do to at least make the multiple
> > exit case behave reasonably? The vectorizer keeps track
>
> > of a "canonical" exit, would it be possible to pass in the main exit
> > edge and use that instead
> > - *type_out = STMT_VINFO_VECTYPE (stmt_info);
> > + if (cond_cst)
> > +{
> > + append_pattern_def_seq (vinfo, stmt_info, pattern_stmt, vectype);
> > + pattern_stmt
> > + = gimple_build_cond (gimple_cond_code (cond_stmt),
> > +gimple_get_lhs (pattern_stm
> -Original Message-
> From: Andrew MacLeod
> Sent: Friday, February 10, 2023 8:59 PM
> To: Richard Biener ; Richard Sandiford
>
> Cc: Tamar Christina ; Tamar Christina via Gcc-
> patches ; nd ;
> j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fi
> > >>> In any case, if you disagree I don’t' really see a way forward
> > >>> aside from making this its own pattern running it before the
> > >>> overwidening
> > pattern.
> > >> I think we should look to see if ranger can be persuaded to provide
> > >> the range of the 16-bit addition, even thou
> On 2/15/23 07:51, Tamar Christina wrote:
> >> In any case, if you disagree I don’t' really see a way forward
> >> aside from making this its own pattern running it before the
> >> overwidening
> >>> pattern.
> > I think we should look to see if ranger can be persuaded to
> > p
> -Original Message-
> From: Andrew MacLeod
> Sent: Wednesday, February 15, 2023 6:43 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix w
Hi Andrew,
>
> all the range-op integer code is in gcc/range-op.cc. As this is a basic
> binary operation, you should be able to get away with implementing a
> single routine, wi_fold () which adds 2 wide int bounds together and
> returns a result. THis si the implelemntaion for operator_plus
> -Original Message-
> From: Andrew MacLeod
> Sent: Wednesday, February 22, 2023 4:42 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix w
Hi Andrew,
> >> Oh yeah, and in case you haven't figured it out on your own, you'll
> >> have to remove WIDEN_MULT_EXPR from the range-ops init table.  This
> >> non-standard mechanism only gets checked if there is no standard
> >> range-op table entry for the tree code :-P
> >>
> > Hmm it looks
> -Original Message-
> From: Andrew MacLeod
> Sent: Thursday, February 23, 2023 4:40 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix w
But this seems like a hack, and it's basically undoing the earlier
transformation. It seems to
me that the open coding is a bad idea.
Do you still want it Richard?
Thanks,
Tamar
>
> Thanks,
> Richard
>
> >
> >>
> >> Some comments in addit
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, February 27, 2023 12:12 PM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of d
Hi All,
This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
* doc/tm.texi (TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Remove.
* doc
Hi All,
This adds range-ops for widening addition and widening multiplication.
I couldn't figure out how to write a test for this. It looks like there are
self tests but not a way to write standalone ones? I did create testcases in
the patch 3/4 which tests the end result.
Bootstrapped Regtest
Hi All,
As Richard S wanted, this now implements a hook
preferred_div_as_shifts_over_mult that indicates whether a target prefers that
the vectorizer decomposes division as shifts rather than multiplication when
possible.
In order to be able to use this we need to check whether the current precis
Hi All,
This replaces the custom division hook with just an implementation through
add_highpart. For NEON we implement the add highpart (Addition + extraction of
the upper highpart of the register in the same precision) as ADD + LSR.
This representation allows us to easily optimize the sequence
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, February 27, 2023 9:33 PM
> To: Tamar Christina via Gcc-patches
> Cc: Tamar Christina ; nd ;
> rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of d
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, February 28, 2023 11:09 AM
> To: Tamar Christina
> Cc: Tamar Christina via Gcc-patches ; nd
> ; rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of d
> -Original Message-
> From: Andrew Carlotti
> Sent: Wednesday, March 1, 2023 4:58 PM
> To: Andrew MacLeod
> Cc: Tamar Christina ; Richard Biener
> ; Richard Sandiford ;
> Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATC
The regression was reported during stage-1. A patch was provided during stage 1
and the discussions around combine stalled.
The regression for AArch64 needs to be fixed in GCC 13. The hit is too big just
to "take".
So we need a way forward, even if it's stage-4.
Thanks,
Tamar
__
>
> On 3/5/23 12:28, Tamar Christina via Gcc-patches wrote:
> >
> > The regression was reported during stage-1. A patch was provided during
> stage 1 and the discussions around combine stalled.
> >
> > The regression for AArch64 needs to be fixed in GCC 13. The hi
1 - 100 of 597 matches
Mail list logo
