When there's a conversion in front of a SLP condition reduction the
code following the reduc-idx SLP chain fails because it assumes
there's only COND_EXPRs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/116241
* tree-vect-loop.cc (vect_create_ep
_ORDER__ == __ORDER_LITTLE_ENDIAN__
>x &= -((VC) vv)[0];
> +#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> + x &= -((VC) vv)[sizeof (__int128) - 1];
> +#else
> + x &= -(unsigned char) (vv[0]);
> +#endif
>vi *= (VI) (VS){ -vs[0], vc[0], vs[1], vi[7], vs[7], vl[7],
23" } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 65
> +#define
r_type) != INTEGER_TYPE))
scalar_type = build_nonstandard_integer_type (GET_MODE_BITSIZE (inner_mode),
TYPE_UNSIGNED (scalar_type));
So possibly vectorizable_internal_function would need to be amended or better,
vector pattern matching be constrai
On Mon, Aug 5, 2024 at 9:14 AM wrote:
>
> From: Pan Li
>
> This patch would like to support the form 1 of the scalar signed
> integer .SAT_ADD. Aka below example:
>
> Form 1:
> #define DEF_SAT_S_ADD_FMT_1(T) \
> T __attribute__((noinline))\
> sat_s_add_##T##_fmt
On Mon, Aug 5, 2024 at 8:49 AM Kyrylo Tkachov wrote:
>
> Hi all,
>
> The code in get_reassociation_width that forms FMAs aggressively when
> they are fully pipelined expects the FMUL reassociation width in the
> target to be less than for FMAs. This doesn't hold for all target
> tunings.
>
> This
On Sun, Aug 4, 2024 at 1:47 PM wrote:
>
> From: Pan Li
>
> The .SAT_TRUNC matching can only perform the type has its mode
> precision.
>
> g_12 = (long unsigned int) _2;
> _13 = MIN_EXPR ;
> _3 = (_Bool) _13;
>
> The above pattern cannot be recog as .SAT_TRUNC (g_12) because the dest
> only has 1
On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ wrote:
>
> Do not convert floats to ints in multiple step if trapping math is
> enabled. This might hide some inexact signals.
>
> Also use correct sign (the sign of the target integer type) for the
> intermediate steps. This only affects undefined b
On Mon, Aug 5, 2024 at 12:36 PM Feng Xue OS wrote:
>
> Some opcodes are missed when determining the smallest scalar type for a
> vectorizable statement. Currently, this bug does not cause any problem,
> because vect_get_smallest_scalar_type is only used to compute max nunits
> vectype, and even st
On Mon, Aug 5, 2024 at 12:34 PM Feng Xue OS wrote:
>
> The function vect_look_through_possible_promotion() fails to figure out root
> definition if casts involves more than two promotions with sign change as:
>
> long a = (long)b; // promotion cast
> -> int b = (int)c; // promotion cast
> Am 03.08.2024 um 20:14 schrieb Jakub Jelinek :
>
> Hi!
>
> I've noticed the following testcase on top of the #embed patchset:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
>
>
The following fixes a compile-time/memory-hog when performing a
large aggregate copy to a small object allocated to a register.
While store_bit_field_1 called by store_integral_bit_field will
do nothign for accesses outside of the target the loop over the
source in store_integral_bit_field will sti
On Fri, Aug 2, 2024 at 11:20 AM Kugan Vivekanandarajah
wrote:
>
>
>
> > On 1 Aug 2024, at 10:46 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, Aug 1, 2024 at 5:31 AM Kugan Vive
On Wed, Jul 31, 2024 at 12:42 PM Mariam Arutunian
wrote:
>
> Gives an opportunity to execute the code on bit level,
>assigning symbolic values to the variables which don't have initial values.
>Supports only CRC specific operations.
>
>Example:
>
>uint8_t crc;
>uint8_t pol
On Wed, Jul 31, 2024 at 10:15 AM Mariam Arutunian
wrote:
>
> This patch adds a new compiler pass aimed at identifying naive CRC
> implementations,
> characterized by the presence of a loop calculating a CRC (polynomial long
> division).
> Upon detection of a potential CRC, the pass prints an i
On Thu, Aug 1, 2024 at 10:40 PM Andrew Pinski wrote:
>
> The problem here is that when forwprop does a copy prop, into a statement,
> we mark the uses of that statement as possibly need to be removed. But it just
> happened that statement was a debug statement, there will be a difference when
> co
On Wed, Jul 31, 2024 at 6:41 PM Richard Sandiford
wrote:
>
> The testcase contains the constant:
>
> arr2 = svreinterpret_u8(svdup_u32(0x0a0d5c3f));
>
> which was initially hoisted by hand, but which gimple optimisers later
> propagated to each use (as expected). The constant was then expanded
On Thu, Aug 1, 2024 at 5:31 AM Kugan Vivekanandarajah
wrote:
>
>
> On Mon, Jul 29, 2024 at 10:11 AM Andrew Pinski wrote:
> >
> > On Mon, Jul 29, 2024 at 12:57 AM Kugan Vivekanandarajah
> > wrote:
> > >
> > > On Thu, Jul 25, 2024 at 10:19 PM Richar
On Wed, Jul 31, 2024 at 5:37 PM Andi Kleen wrote:
>
> On Wed, Jul 31, 2024 at 04:02:22PM +0200, Richard Biener wrote:
> > The following improves release_pages when using the madvise path
> > to sort the freelist to get more page entries contiguous and possibly
> > relea
On Thu, Aug 1, 2024 at 12:30 AM Andrew Pinski wrote:
>
> When this pattern was converted from being only dealing with 0/-1, we missed
> that if `e == f` is true
> then the optimization is wrong and needs an extra check for that.
>
> This changes the patterns to be:
> /* (a ? x : y) != (b ? x : y)
On Wed, Jul 31, 2024 at 9:00 PM Qing Zhao wrote:
>
> Hi, Kewen,
>
> Thanks a lot for fixing this testing case issue.
> Yes, the change LGTM though I can’t approve it.
OK.
Richard.
> Qing
>
> > On Jul 31, 2024, at 05:22, Kewen.Lin wrote:
> >
> > Hi,
> >
> > As Andrew pointed out in PR116148, fa
The following improves release_pages when using the madvise path
to sort the freelist to get more page entries contiguous and possibly
release them. This populates the unused prev pointer so the reclaim
can then easily unlink from the freelist without re-ordering it.
The paths not having madvise d
On Wed, 10 Jul 2024, Richard Biener wrote:
> The loop unrolling code assumes that one third of all volatile accesses
> can be possibly optimized away which is of course not true. This leads
> to excessive unrolling in some cases. The following tracks the number
> of stmts with sid
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes for scalar
and complex float modes.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK this way?
Thanks,
Richard.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
gcc/
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
On Wed, 31 Jul 2024, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 02:43:36PM +0200, Richard Biener wrote:
> > diff --git a/gcc/config/i386/i386-modes.def
> > b/gcc/config/i386/i386-modes.def
> > index 6d8f1946f3a..2cc03e30f13 100644
> > --- a/gcc/config/i386/i386-mod
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 11:33 AM Richard Biener wrote:
> >
> > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> >
> > > On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
> > > >
> > > > On Wed, 31 Jul
On Wed, Jul 31, 2024 at 1:21 PM Tobias Burnus wrote:
>
> Hi Richard, hi all,
>
> Richard Biener wrote:
>
> Looking at pass_omp_target_link::execute I wonder iff find_link_var_op
> shouldn't simply do the substitution? Aka
>
> This seems to work ...
>
> --
On Tue, Jul 30, 2024 at 5:26 PM Andrew Pinski wrote:
>
> When this pattern was converted from being only dealing with 0/-1, we missed
> that if `e == f` is true
> then the optimization is wrong and needs an extra check for that.
>
> This changes the patterns to be:
> /* (a ? x : y) != (b ? x : y)
On Tue, Jul 30, 2024 at 5:25 PM Andrew Pinski wrote:
>
> The problem here is that in generic types of comparisons don't need
> to be boolean types (or vector boolean types). And fixes that by making
> sure the types of the conditions match before doing the optimization.
>
> Bootstrapped and tested
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
> >
> > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> >
> > > On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> > > >
> > > > On We
On Tue, 30 Jul 2024, Paul Koning wrote:
>
>
> > On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
> >
> > The following adds a target hook to specify whether regs of MODE can be
> > used to transfer bits. The hook is supposed to be used for value-numbering
When we gimplify &MEM[0B + 4] we are re-folding the address in case
types are not canonical which ends up with a constant address that
recompute_tree_invariant_for_addr_expr ICEs on. Properly guard
that call.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/1014
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> >
> > On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > > OK. Richard, can you please mention the above in the comment why
> > > XFmode is rejected in the hook?
> > >
> > > Later, we c
On Wed, Jul 31, 2024 at 6:32 AM liuhongt wrote:
>
> Ok for trunk?
OK for www.
Richard.
> ---
> htdocs/gcc-14/changes.html| 7 +++
> htdocs/gcc-14/porting_to.html | 9 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
On Tue, Jul 30, 2024 at 10:24 PM Jeff Law wrote:
>
>
> This fixes a testsuite regression seen on m68k after some of the recent
> ext-dce changes. Ultimately Richard S and I have concluded the bug was
> a latent issue in subreg simplification.
>
> Essentially when simplifying something like
>
> (s
On Tue, Jul 30, 2024 at 7:33 PM Tobias Burnus wrote:
>
> Richard Biener wrote:
> > On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
> >> Inside pass_omp_target_link::execute, there is a call to
> >> gimple_regimplify_operands but the value e
On Tue, Jul 30, 2024 at 7:05 PM Jakub Jelinek wrote:
>
> Hi!
>
> C23 added in N2956 ( https://open-std.org/JTC1/SC22/WG14/www/docs/n2956.htm )
> two new attributes, which are described as similar to GCC const and pure
> attributes, but they aren't really same and it seems that even the paper
> is
On Tue, Jul 30, 2024 at 5:43 PM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Host systems with only MMX and no SSE2 should be really rare now.
> Let's remove the MMX code path to keep the number of custom
> implementations the same.
>
> The SSE2 code path is also somewhat dubious now (nearly everyt
> Am 30.07.2024 um 19:22 schrieb Alexander Monakov :
>
>
> On Tue, 30 Jul 2024, Andi Kleen wrote:
>>> I have looked at this code before. When AVX2 is available, so is SSSE3,
>>> and then a much more efficient approach is available: instead of comparing
>>> against \r \n \\ ? one-by-one, build
The following adds support for vector conditionals in C. The support
was nearly there already but c_objc_common_truthvalue_conversion
rejecting vector types. Instead of letting them pass there unchanged
I chose to instead skip it when parsing conditionals instead as a
variant with less possible f
On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is p
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > > TARGET_SSE_MATH some day...)
> > > >
> > > &g
On Tue, 30 Jul 2024, Filip Kastl wrote:
> > > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > > the final block needs adjustment you know there was a path from
> > > > the default case to it which means one of its predecessors is dominated
> > > > by the default case?
On Tue, 30 Jul 2024, Uros Bizjak wrote:
> On Tue, Jul 30, 2024 at 1:07 PM Uros Bizjak wrote:
> >
> > On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
> > >
> > > The following implements the hook, excluding x87 modes for scalar
> > > and complex
On Sat, Jul 27, 2024 at 4:29 AM Andrew Pinski wrote:
>
> While working on isel, I found that the current way of doing
> current_properties
> in function can easily make a mistake and having to do stuff like `(a & b )
> == 0`
> and `a |= b;` and `a &= ~b;` is not so obvious what was going on.
> S
* cp/tree.cc: Likewise.
> * expr.cc: Likewise.
> * fortran/trans-array.cc: Likewise.
> * fortran/trans-openmp.cc: Likewise.
> * rust/backend/rust-tree.cc: Likewise.
>
> Suggested-by: Richard Biener
> Signed-off-by: Alejandro Col
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes for scalar
and complex float modes.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
gcc/config/i3
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
On Tue, 30 Jul 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 18, 2024 10:00 AM
> > To: Tamar Christina
> > Cc: GCC Patches ; Richard Sandiford
> >
> > Subject: RE: [RFC][middle-end] S
On Tue, 30 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 30 Jul 2024, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
> >> >
> >> >>
> &
On Tue, 30 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Richard Sandiford
> >> > Sent: Monday, J
On Tue, Jul 30, 2024 at 5:08 AM wrote:
>
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_
On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
>
> The problem is code like:
>
>MEM [(c_char * {ref-all})&arr2]
>
> where arr2 is the value expr '*arr2$13$linkptr'
> (i.e. indirect ref + decl name).
>
> Insidepass_omp_target_link::execute, there is a call to
> gimple_regimplify_operands
On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>
>
> > -Original Message-
> > From: Richard Sandiford
> > Sent: Monday, July 29, 2024 9:43 PM
> > To: Richard Biener
> > Cc: Prathamesh Kulkarni ; gcc-
> > patc...@gcc.gnu.org
> >
On Mon, 29 Jul 2024, Filip Kastl wrote:
> Hi Richard,
>
> > > Sorry, I'm not sure if I understand. Are you suggesting something like
> > > this?
> > >
> > > if (idom(default bb) == cond bb)
> > > {
> > > if (exists a path from default bb to final bb)
> > > {
> > > idom(final bb) = cond
On Mon, 29 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> >> I think those should be considered as true by the hook, not
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
&g
On Mon, 29 Jul 2024, Richard Biener wrote:
> The following implements the hook, excluding x87 modes.
Jakub correctly pointed out complex modes, so I've adjusted the hook to
the following which might be easier to parse (and handles decimal
FP modes as returning true). Re-testing in
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> > The following adds a target hook to specify whether regs of MODE can be
> > used to transfer bits. The hook is supposed to be used for value-numbering
> > to d
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
gcc/config/i386/i386.cc | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/config/i386/i386.cc b/gcc/config
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
upper bound,
like 2? Maybe even have MAX_NUM_POLY_INT_COEFFS or
NUM_POLY_INT_COEFFS_BITS in poly-int.h and constrain NUM_POLY_INT_COEFFS.
The patch looks reasonable over all, but Richard S. should have a say
about the abstraction you chose and the poly-int adjustment.
Thanks,
Richard.
> S
On Mon, Jul 29, 2024 at 10:55 AM Alejandro Colomar wrote:
>
> Hi Richard,
>
> On Mon, Jul 29, 2024 at 10:27:35AM GMT, Richard Biener wrote:
> > On Sun, Jul 28, 2024 at 4:16 PM Alejandro Colomar wrote:
> > >
> > > There were two identical definitions, and no
On Sun, Jul 28, 2024 at 5:25 AM wrote:
>
> From: Pan Li
>
> After add the matching for .SAT_SUB when one op is IMM, there
> will be a new root PLUS_EXPR for the .SAT_SUB pattern. For example,
>
> Form 3:
> #define DEF_SAT_U_SUB_IMM_FMT_3(T, IMM) \
> T __attribute__((noinline)) \
On Mon, Jul 29, 2024 at 10:11 AM Andrew Pinski wrote:
>
> On Mon, Jul 29, 2024 at 12:57 AM Kugan Vivekanandarajah
> wrote:
> >
> > On Thu, Jul 25, 2024 at 10:19 PM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 25, 2024 at 4:42 AM Kugan Vivekana
On Mon, Jul 29, 2024 at 9:57 AM wrote:
>
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_
On Sun, Jul 28, 2024 at 4:16 PM Alejandro Colomar wrote:
>
> There were two identical definitions, and none of them are available
> where they are needed for implementing _Lengthof(). Merge them, and
> provide the single definition in gcc/tree.{h,cc}, where it's available
> for _Lengthof().
>
> S
> Am 28.07.2024 um 16:27 schrieb Jonathan Wakely :
>
> Bootstrapped on x86_64-linux and for msp430-elf cross with and without
> binutils for the target to verify the error is printed as expected.
>
> The $invoked variable will be one of as, collect-ld, nm, or dsymutil,
> i.e. the tool that th
> Am 28.07.2024 um 01:34 schrieb Sam James :
>
> Per gccint, dg-add-options must be placed after all dg-options directives.
>
> gcc/testsuite/ChangeLog:
>
>* gcc.target/riscv/rvv/base/cmpmem-2.c: Fix dg-add-options order.
Ok for both patches
Richard
> ---
> Simple dejagnu directive f
> Am 28.07.2024 um 06:41 schrieb Andrew Pinski :
>
> While doing some other cleanups with the properties I noticed that
> debug_properties
> was not updated for some of the new properties. So instead of just updating
> the function,
> this moves the properties over to its own .def file so we
On Fri, Jul 26, 2024 at 11:20 AM wrote:
>
> From: Pan Li
>
> This patch would like to support .SAT_SUB when one of the op
> is IMM. Aka below 1-4 forms.
>
> Form 1:
> #define DEF_SAT_U_SUB_IMM_FMT_1(T, IMM) \
> T __attribute__((noinline)) \
> sat_u_sub_imm##IMM##_##T##_fmt_1 (T y)
On Thu, May 30, 2024 at 2:11 AM Patrick O'Neill wrote:
>
> From: Greg McGary
>
> gcc/ChangeLog:
> * gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent
> divide-by-zero.
> * testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove dg-ice.
> ---
> No changes in v3. Depends
On Thu, Jul 25, 2024 at 3:34 PM Robin Dapp wrote:
>
> Hi,
>
> In preparation for the maskload else operand I split off this patch. The
> patch
> looks through SSA names for the conditions passed to inverse_conditions_p
> which
> helps match.pd recognize more redundant vec_cond expressions. It
On Sun, Jul 21, 2024 at 11:12 AM Feng Xue OS
wrote:
>
> Hi,
>
> I composed some patches to generalize lane-reducing (dot-product is a
> typical representative) pattern recognition, and prepared a RFC document so
> as to help
> review. The original intention was to make a complete solution for
On Sun, Jul 21, 2024 at 11:15 AM Feng Xue OS
wrote:
>
> The work for RFC
> (https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657860.html)
> involves not a little code change, so I have to separate it into several
> batches
> of patchset. This and the following patches constitute the first bat
On Thu, 18 Jul 2024, Filip Kastl wrote:
> On Thu 2024-07-18 12:07:42, Richard Biener wrote:
> > On Wed, 17 Jul 2024, Filip Kastl wrote:
> > > > > + }
> > > > > +
> > > > > + vec v;
> > > >
On Fri, Jul 26, 2024 at 1:15 PM Richard Sandiford
wrote:
>
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Friday, July 26, 2024 10:43 AM
> >> To: Tamar Christina
> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> >> ; Marcus Shawcroft
>
On Fri, Jul 26, 2024 at 10:50 AM Hongyu Wang wrote:
>
> Hi,
>
> When introducing munroll-only-small-loops, the option was marked as
> Target Save and added to -O2 default which makes attribute(optimize)
> resets target option and causing error when cmdline has O1 and
> funciton attribute has O2 an
On Fri, Jul 26, 2024 at 10:14 AM Haochen Jiang wrote:
>
> Hi all,
>
> I have added related testcases into the patch.
>
> Ok for trunk and backport to GCC 14, GCC 13 and GCC 12?
Hmm, it might be OK for 14.2 still, even without a new RC. But please
wait until
after 14.2 is released unless Jakub al
On Fri, Jul 26, 2024 at 12:55 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> - Run the target_effective tail_call checks without optimization to
> match the actual test cases.
> - Add an extra check for external tail calls to handle targets like
> powerpc that cannot tail call between different ob
On Fri, Jul 26, 2024 at 12:55 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> The "tail call must be the same type" message is common on some
> targets with C++, or without optimization. It is generated
> when gcc believes there is an access of the return value
> after the call. However usually it
> Am 26.07.2024 um 11:40 schrieb Tamar Christina :
>
> Hi All,
>
> For historical reasons AArch64 has TI mode vector types but does not consider
> TImode a vector mode.
>
> What's happening in the PR is that get_vectype_for_scalar_type is returning
> vector(1) TImode for a TImode scalar. Th
> Am 26.07.2024 um 11:29 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, July 26, 2024 10:24 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; ktkac...@gcc.gnu.org
>> Subject
On Fri, Jul 26, 2024 at 6:37 AM Andrew Pinski wrote:
>
> This is a small cleanup of the duplicating comparison code.
> There is code generation difference but only for -O0 and -fno-tree-ter
> (both of which will be fixed in a later patch).
> The difference is instead of skipping the first use if t
On Fri, Jul 26, 2024 at 6:37 AM Andrew Pinski wrote:
>
> This is just a small cleanup to isel and no functional changes just.
> The loop inside pass_gimple_isel::execute looked was getting too
> deap so let's fix that by moving it to its own function.
>
> Bootstrapped and tested on x86_64-linux-gn
On Fri, Jul 26, 2024 at 6:37 AM Andrew Pinski wrote:
>
> While doing cleanups on this code I noticed that we do the duplicate
> of comparisons at -O0. For C and C++ code this makes no difference as
> the gimplifier never produces COND_EXPR. But it could make a difference
> for other front-ends.
>
On Thu, Jul 25, 2024 at 10:57 PM Andrew Pinski wrote:
>
> On Thu, Jul 25, 2024 at 10:20 AM Richard Biener
> wrote:
> >
> >
> >
> > > Am 25.07.2024 um 17:56 schrieb Andrew Pinski :
> > >
> > > It was noticed if we have `.VEC_SHL_INSERT ({ 0,
On Thu, Jul 25, 2024 at 10:25 PM Andrew Pinski wrote:
>
> The problem here is the aarch64 backend enables -mearly-ra at -O2 and above
> but
> it is not marked as an Optimization in the .opt file so enabling it sometimes
> reset the target options when going from -O1 to -O2 for the first time.
>
>
> Am 25.07.2024 um 17:56 schrieb Andrew Pinski :
>
> It was noticed if we have `.VEC_SHL_INSERT ({ 0, ... }, 0)` it was not being
> simplified to just `{ 0, ... }`. This was generated from the autovectorizer
> (maybe even on accident, see PR tree-optmization/116081).
>
> This adds a few SVE t
The following avoids some useless work when the SLP discovery limit
is reached, for example allocating a node to cache the failure
and starting discovery on split store groups when analyzing BBs.
It does not address the issue in the PR which is a gratious budget
for discovery when the store group
On Tue, Jul 23, 2024 at 4:07 PM Sam James wrote:
>
> At -O1, the intention is that we compile things in a "reasonable" amount
> of time (ditto memory use). In particular, we try to especially avoid
> optimizations which scale poorly on pathological cases, as is the case
> for large machine-generat
On Thu, Jul 25, 2024 at 4:42 AM Kugan Vivekanandarajah
wrote:
>
> On Tue, Jul 23, 2024 at 11:56 PM Richard Biener
> wrote:
> >
> > On Tue, Jul 23, 2024 at 10:27 AM Kugan Vivekanandarajah
> > wrote:
> > >
> > > On Tue, Jul 23, 2024 at 10:35 AM Andrew
On Thu, Jul 25, 2024 at 4:18 AM Andrew Pinski wrote:
>
> With constants we can match `~(a | CST)` into `CST & ~a`.
> Likewise `~(a & CST)` into `CST | ~a`.
>
> Built and tested for aarch64-linux-gnu with no regressions.
Similar, I think this should be in ISEL instead.
> PR target/116013
On Thu, Jul 25, 2024 at 4:16 AM Andrew Pinski wrote:
>
> To better create rtl directly from gimple, we can use
> these already internal functions from the gimple.
>
> That is simplify `a & ~b` into BIT_ANDN.
> Likewise `a | ~b` into BIT_IORN.
> We only want to do this late after vectorization as s
The following fixes the code generation difference when using
a typedef for the scalar type. The issue is using a pointer
equality test for an INTEGER_CST which fails when the types
are different variants.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/
When we move a store out of an inner loop and remove a clobber in
the process, analysis of the inner loop can run into the clobber
via the meta-data and crash when accessing its basic-block. The
following avoids this by clearing the VDEF which is how it identifies
already processed stores.
Bootst
501 - 600 of 3347 matches
Mail list logo
