On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote:
>
> Hi all,
>
> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just
> do it because the GCC middle-end models DIVMOD's return value as
> "complex int" type, and there are no vector equivalents of that type.
>
> Therefore, th
On Fri, May 26, 2023 at 8:44 PM Roger Sayle wrote:
>
>
> This patch enhances one of the optimizations in simplify_binary_operation_1
> to allow it to simplify RTL expressions in modes than HOST_WIDE_INT by
> replacing a use of HWI_COMPUTABLE_MODE_P and UINTVAL with wide_int.
>
> The motivating exa
On Mon, 29 May 2023, Jiufu Guo wrote:
> Hi,
>
> Previously, I was investigating some struct parameters and returns related
> PRs 69143/65421/108073.
>
> Investigating the issues case by case, and drafting patches for each of
> them one by one. This would help us to enhance code incrementally.
>
On Mon, May 29, 2023 at 6:20 PM Martin Jambor wrote:
>
> Hi,
>
> there have been concerns that linear searches through DECL_ARGUMENTS
> that are often necessary to compute the index of a particular
> PARM_DECL which is the key to results of IPA-CP can happen often
> enough to be a compile time iss
On Tue, May 30, 2023 at 7:06 AM Ajit Agarwal wrote:
>
> Hello Richard:
>
> On 22/05/23 6:26 pm, Richard Biener wrote:
> > On Thu, May 18, 2023 at 9:14 AM Ajit Agarwal wrote:
> >>
> >> Hello All:
> >>
> >> This patch improves code sinking pass to sink statements before call to
> >> reduce
> >> re
On Tue, May 30, 2023 at 8:07 AM Kito Cheng via Gcc-patches
wrote:
>
> GNU vector extensions is widly used around this world, and this patch
> enable that with RISC-V vector extensions, this can help people
> leverage existing code base with RVV, and also can write vector programs in a
> familiar w
On Fri, 26 May 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi. Thanks for your analysis and helps.
>
> >> We could simply retain the original
> >> incrementing IV for loop control and add the decrementing
> >> IV for computing LEN in addition to that and leave IVOPTs
> >> sorting out to eventually
On Tue, May 30, 2023 at 11:17 AM juzhe.zh...@rivai.ai
wrote:
>
> In the future, we will definitely mixing VLA and VLS-vlmin together in a
> codegen and it will not cause any issues.
> For VLS-vlmin, I prefer it is used in length style auto-vectorization (I am
> not sure since my SELECT_VL patch
On Mon, May 8, 2023 at 12:21 AM Andrew Pinski via Gcc-patches
wrote:
>
> This moves the `a <= CST1 ? MAX : a` optimization
> from phiopt to match. It just adds a new pattern to match.pd.
>
> There is one more change needed before being able to remove
> minmax_replacement from phiopt.
>
> A few not
On Mon, May 8, 2023 at 7:27 AM Andrew Pinski via Gcc-patches
wrote:
>
> This patch adds the support for match that was implemented for PR 87913 in
> phiopt.
> It implements it by adding support to minmax_from_comparison for the check.
> It uses the range information if available which allows to p
On Tue, May 9, 2023 at 9:06 AM liuhongt via Gcc-patches
wrote:
>
> The patch doesn't handle:
> 1. cast64_to_32,
> 2. memory source with rsize < range.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
OK and sorry for the delay.
Richard.
> gcc/ChangeLog:
>
>
On Wed, 17 May 2023, Jiufu Guo wrote:
> Hi,
>
> This patch tries to optimize "(X - N * M) / N + M" to "X / N".
But if that's valid why not make the transform simpler and transform
(X - N * M) / N to X / N - M instead?
You use the same optimize_x_minus_NM_div_N_plus_M validator for
the division
On Tue, 30 May 2023, juzhe.zh...@rivai.ai wrote:
> Ok.
>
> It seems that for this conditions:
>
> + /* If we're vectorizing a loop that uses length "controls" and
> + can iterate more than once, we apply decrementing IV approach
> + in loop control. */
> + if (LOOP_VINFO_CAN_USE_PARTI
On Tue, May 23, 2023 at 11:28 AM Sebastian Huber
wrote:
>
> On 10.01.23 16:38, Sebastian Huber wrote:
> > On 19/12/2022 17:02, Sebastian Huber wrote:
> >> Build libatomic for all targets. Use gthr.h to provide a default
> >> implementation. If the thread model is "single", then this
> >> impleme
On Tue, 30 May 2023, Kewen.Lin wrote:
> on 2023/5/30 17:26, juzhe.zh...@rivai.ai wrote:
> > Ok.
> >
> > It seems that for this conditions:
> >
> > + /* If we're vectorizing a loop that uses length "controls" and
> > + can iterate more than once, we apply decrementing IV approach
> > + i
On Tue, 30 May 2023, Richard Sandiford wrote:
> My understanding was that we went into this knowing that the IVs
> would defeat SCEV analysis. Apparently that wasn't a problem for RVV,
> but it's not surprising that it is a problem in general.
>
> This isn't just about SELECT_VL though. We use
On Tue, May 30, 2023 at 12:17 PM Sebastian Huber
wrote:
>
> On 30.05.23 11:53, Richard Biener wrote:
> > On Tue, May 23, 2023 at 11:28 AM Sebastian Huber
> > wrote:
> >> On 10.01.23 16:38, Sebastian Huber wrote:
> >>> On 19/12/2022 17:02, Sebastian Huber wrote:
> Build libatomic for all tar
On Mon, May 29, 2023 at 5:21 AM Hongtao Liu via Gcc-patches
wrote:
>
> ping.
>
> On Mon, May 8, 2023 at 9:59 AM liuhongt wrote:
> >
> > > > @@ -4799,7 +4800,8 @@ vect_create_vectorized_demotion_stmts (vec_info
> > > > *vinfo, vec *vec_oprnds,
> > > >stmt_v
On Tue, May 30, 2023 at 9:35 AM Ajit Agarwal wrote:
>
> Hello Richard:
>
> On 30/05/23 12:34 pm, Richard Biener wrote:
> > On Tue, May 30, 2023 at 7:06 AM Ajit Agarwal wrote:
> >>
> >> Hello Richard:
> >>
> >> On 22/05/23 6:26 pm, Richard Biener wrote:
> >>> On Thu, May 18, 2023 at 9:14 AM Ajit A
On Tue, 30 May 2023, Richard Sandiford wrote:
> Richard Biener writes:
> >> But how easy would it be to extend SCEV analysis, via a pattern match?
> >> The evolution of the IV phi wrt the inner loop is still a normal SCEV.
> >
> > No, the IV isn't a normal SCEV, the final value is different.
>
>
On Tue, 30 May 2023, juzhe.zhong wrote:
> This patch will generate the number of rgroup ?mov? instructions inside the
> loop. This is unacceptable. For example?if number of rgroups=3? will be 3 more
> instruction in loop. If this patch is necessary? I think I should find a way
> to fix it.
That's
On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> Hi?all. I have posted my several investigations:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html
On Tue, May 30, 2023 at 4:21 PM Jan Hubicka wrote:
>
> > On Mon, May 29, 2023 at 6:20 PM Martin Jambor wrote:
> > >
> > > Hi,
> > >
> > > there have been concerns that linear searches through DECL_ARGUMENTS
> > > that are often necessary to compute the index of a particular
> > > PARM_DECL which
On Tue, May 30, 2023 at 4:49 PM Alexander Monakov wrote:
>
>
> On Thu, 25 May 2023, Richard Biener wrote:
>
> > On Wed, May 24, 2023 at 8:36 PM Alexander Monakov
> > wrote:
> > >
> > >
> > > On Wed, 24 May 2023, Richard Biener via Gcc-patches w
On Tue, May 30, 2023 at 9:01 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/30/23 08:36, Uros Bizjak via Gcc-patches wrote:
> > gcc/ChangeLog:
> >
> > * rtl.h (comparison_dominates_p): Change return type from int to bool.
> > (condjump_p): Ditto.
> > (any_condjump_p): Ditto.
> >
On Wed, May 31, 2023 at 3:35 AM Cui, Lili wrote:
>
> Hi,
>
> This patch is to fix ICE in rewrite_expr_tree_parallel.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
>
> Bootstrapped and regtested. Ok for trunk?
OK.
> Regards
> Lili.
>
> 1. Limit the value of tree-reassoc-width to IntegerRa
On Wed, May 31, 2023 at 6:34 AM Andrew Pinski via Gcc-patches
wrote:
>
> After r14-1014-gc5df248509b489364c573e8, GCC started to emit
> directly a zero_extract for `(t1&0x8)!=0`. This introduced
> a small regression where ifcvt would not do the ifconversion
> as there is now a paradoxical subreg i
On Wed, May 31, 2023 at 7:31 AM Sebastian Huber
wrote:
>
> On 30.05.23 13:17, Richard Biener wrote:
> > The alternative would be to provide the required subset of atomic
> > library functions from libgcov.a and emit calls to that directly?
> > The locked data isn't part of any ABI so no compatibil
On Wed, 31 May 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> >
> >> Hi?all. I have posted my several investigations:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html
> >> https://gcc.gnu.org/pipermail/gcc-patches
On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard.
>
> >> I don't object though. It just feels like we're giving up easily.
> >> And that's a bit frustrating, since this potential problem was flagged
> >> ahead of time.
>
> I can take a look at it. Would you mind giving me some hin
On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richard.
> Seems that this patch's approach is ok to trunk?
> Maybe the only thing we should do is to wait Kewen's testing feedback, am I
> right ?
Can you repost the patch with Kevens fix and state how you tested it?
Thanks,
Richard.
The following keeps track of the number of edges we avoid to create
because they redundandly feed ESCAPED. It also avoids printing
a header for -details when not using -details.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-structalias.cc (constraint_stats::num_
This improves the edge avoidance heuristic by re-ordering the
topological sort of the graph to make sure the component with
the ESCAPED node is processed first. This improves the number
of created edges which directly correlates with the number
of bitmap_ior_into calls from 141447426 to 239596 and
On Wed, May 31, 2023 at 6:08 PM Martin Jambor wrote:
>
> Hello,
>
> On Wed, May 31 2023, Richard Biener wrote:
> > On Tue, May 30, 2023 at 4:21 PM Jan Hubicka wrote:
> >>
> >> > On Mon, May 29, 2023 at 6:20 PM Martin Jambor wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > there have been concerns
On Thu, Jun 1, 2023 at 9:51 AM liuhongt via Gcc-patches
wrote:
>
> For the testcase in the PR, we have
>
> br64 = br;
> br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);
>
> n->n: 0x300200.
> n->range: 32.
> n->type: uint64.
>
> The original code assumes n->rang
On Thu, 1 Jun 2023, juzhe.zh...@rivai.ai wrote:
> This patch is no difference from V2.
> Just add PR tree-optimization/109971 as Kewen's suggested.
>
> Already bootstrapped and Regression on X86 no difference.
>
> Ok for trunk ?
OK.
Richard.
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
>
On Thu, 1 Jun 2023, Jiufu Guo wrote:
> Hi,
>
> Jiufu Guo via Gcc-patches writes:
>
> > Hi,
> >
> > Richard Biener writes:
> >
> >> On Wed, 17 May 2023, Jiufu Guo wrote:
> >>
> >>> Hi,
> >>>
> >>> This patch tries to optimize "(X - N * M) / N + M" to "X / N".
> >>
> >> But if that's valid why
On Mon, 29 May 2023, Martin Jambor wrote:
> Hi,
>
> PRs 68930 and 92497 show that when IPA-CP figures out constants in
> aggregate parameters or when passed by reference but the loads happen
> in an inlined function the information is lost. This happens even
> when the inlined function itself wa
On Thu, 1 Jun 2023, Andre Vieira (lists) wrote:
> Hi,
>
> This is a follow-up of the internal function patch to add widening and
> narrowing patterns. This patch improves the inliner cost estimation for
> internal functions.
I have no idea why calls are special in IPA analyze_function_body
and
On Fri, Jun 2, 2023 at 3:32 AM Jason Merrill via Gcc-patches
wrote:
>
> I ended up deciding not to apply the DECL_NOT_OBSERVABLE patch that you
> approved in stage 3 because I didn't feel like it was fully baked; I'm happy
> with this version now, which seems like a more broadly useful flag.
>
> T
On Fri, Jun 2, 2023 at 4:44 AM Jason Merrill via Gcc-patches
wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
OK.
> -- 8< --
>
> In PR95226, the testcase was failing because we tried to output_constant a
> NOP_EXPR to float from a double REAL_CST, and so we output a double where
> the caller
On Fri, Jun 2, 2023 at 9:36 AM Andrew Pinski via Gcc-patches
wrote:
>
> The problem here is DSE was not taking into account the address space
> which meant if you had two addresses say `fs:0` and `gs:0` (on x86_64),
> DSE would think they were the same and remove the first store.
> This fixes that
On Fri, Jun 2, 2023 at 11:24 AM Alexander Monakov wrote:
>
>
> On Fri, 2 Jun 2023, Matthias Kretz wrote:
>
> > > Okay, I see opinions will vary here. I was thinking about our immintrin.h
> > > which is partially implemented in terms of generic vectors. Imagine we
> > > extend UBSan to trap on sign
> >
> > > > On Wed, May 24, 2023 at 8:36 PM Alexander Monakov
> > > > wrote:
> > > > >
> > > > >
> > > > > On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
> > > > >
> > > > > > I’
> Am 02.06.2023 um 21:12 schrieb Iain Sandoe via Gcc-patches
> :
>
> @David: I am not sure what sets the ABI on AIX (for Darwin, it is effectively
> "whatever the system compiler [Apple gcc-4] does") but from an inspection of
> the code, it seems that (if the platform should honour #pragma pa
> Am 05.06.2023 um 06:42 schrieb Andrew Pinski via Gcc-patches
> :
>
> On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS) named
> m2,
> this conflicts with the langauge m2. So when you do a `make clean`, it will
> remove
> the m2 directory and then a build will fail. Now
On Fri, Jun 2, 2023 at 11:54 AM SenthilKumar.Selvaraj--- via
Gcc-patches wrote:
>
> Hi,
>
> This patch fixes an ICE when an optimize attribute changes the prevailing
> optimization level.
>
> I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 describing the
> same ICE for the sh target, w
On Fri, Jun 2, 2023 at 6:57 PM Jason Merrill via Gcc-patches
wrote:
>
> Since Jonathan approved the library change, I'm looking for middle-end
> approval for the tree-eh change, even without advice on the potential
> follow-up.
>
> On 5/24/23 14:55, Jason Merrill wrote:
> > Middle-end folks: any t
On Sun, Jun 4, 2023 at 11:41 PM Jeff Law via Gcc-patches
wrote:
>
> While investigating a RISC-V backend patch from Jivan I noticed a
> regression in terms of dynamic instruction counts for the omnetpp
> benchmark in spec2017.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620577.html
>
>
On Mon, Jun 5, 2023 at 7:43 AM Andrew Pinski wrote:
>
> On Sun, Jun 4, 2023 at 10:24 PM Richard Biener via Gcc-patches
> wrote:
> >
> >
> >
> > > Am 05.06.2023 um 06:42 schrieb Andrew Pinski via Gcc-patches
> > > :
> > >
>
On Mon, Jun 5, 2023 at 3:49 PM Andrew Stubbs wrote:
>
> On 30/05/2023 07:26, Richard Biener wrote:
> > On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote:
> >>
> >> Hi all,
> >>
> >> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just
> >> do it because the GCC middle-end mo
On Mon, Jun 5, 2023 at 8:41 PM Jeff Law wrote:
>
>
>
> On 6/5/23 00:29, Richard Biener wrote:
>
> >
> > But then for example x86 has smaller encoding for byte ops and while
> > widening is easily done later, truncation is not.
> Sadly, the x86 costing looks totally bogus here. We actually emit th
On Tue, Jun 6, 2023 at 6:17 AM wrote:
>
> From: Juzhe-Zhong
>
> This patch enables basic VLA SLP auto-vectorization.
> Consider this following case:
> void
> f (uint8_t *restrict a, uint8_t *restrict b)
> {
> for (int i = 0; i < 100; ++i)
> {
> a[i * 8 + 0] = b[i * 8 + 7] + 1;
>
The gimplifier can elide initialized constant automatic variables
to static storage in which case TARGET_EXPR gimplification needs
to avoid emitting a CLOBBER for them since their lifetime is no
longer limited. Failing to do so causes spurious dangling-pointer
diagnostics on the added testcase for
The following improves solution_set_expand to require one less
iteration over the bitmap and avoid changing the bitmap we iterate
over. Plus we handle adjacent subvars in the ID space (the common case)
and use bitmap_set_range. This cuts a bit less than 10% off the PTA
time from the testcase in t
On Mon, 5 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
>
> This patch address comments from Richard and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have target dependent optimization in case of
> leng
On Wed, 7 Jun 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 &&
> vec_num == 1)
> Should I make SELECT_VL stuff out side the loop?
>
> for (i = 0; i < vec_num; i++)
> for (j = 0; j < ncopies; j++)
>
No, but please put assertions i
On Tue, Jun 6, 2023 at 11:53 AM Florian Weimer via Gcc-patches
wrote:
>
> The eh_frame value is only used by linear_search_fdes, not the binary
> search directly in find_fde_tail, so the bug is not immediately
> apparent with most programs.
>
> Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de
> Am 07.06.2023 um 18:52 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> I'm getting
> +FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
> signal terminated program cc1)
> +FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
> +FAIL: gcc.target/i386/3d
> Am 07.06.2023 um 18:59 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> We have expand_doubleword_clz for a couple of years, where we emit
> double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
> else return CLZ (high_word);
> We can do something similar for CTZ a
When folding two conversions in a row we use TYPE_PRECISION but
that's invalid for VECTOR_TYPE. The following fixes this by
using element_precision instead.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* match.pd (two conversions in a row): Use element_precision
to
The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
ICEs when tree checking is enabled. This should avoid wrong-code
in cases like PR110182 and instead ICE.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu, I guess
there will be some fallout of such change ...
* tr
On Fri, 9 Jun 2023, Jiufu Guo wrote:
> Hi,
>
> As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P (mode))"
> in "try_const_anchors".
> This assert seems correct because the function try_const_anchors cares
> about integer values currently, and modes other than SCALAR_INT_MODE_P
> are
On Thu, 8 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
> Co-authored-by: Richard Biener
>
> This patch address comments from Richard && Richi and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have targ
On Wed, 7 Jun 2023, Jiufu Guo wrote:
> Hi,
>
> This patch tries to optimize "(X - N * M) / N" to "X / N - M".
> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe
> wrap/overflow/underflow. So, it is valid that "X - N * M" does
> not cross zero and does not wrap/overflow/underflow.
>
On Fri, 9 Jun 2023, Richard Sandiford wrote:
> guojiufu writes:
> > Hi,
> >
> > On 2023-06-09 16:00, Richard Biener wrote:
> >> On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >>
> >>> Hi,
> >>>
> >>> As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P
> >>> (mode))"
> >>> in "try_const_anc
On Thu, Jun 8, 2023 at 1:24 PM Lehua Ding wrote:
>
> Hi,
>
> This patch fixes the problem that the loop in the tsvc s176 function is
> optimized and removed because `iterations/LEN_1D` is 0 (where iterations
> is set to 1, LEN_1D is set to 32000 in tsvc.h).
>
> This testcase passed on x86 and
On Thu, Jun 8, 2023 at 11:15 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Jun 08, 2023 at 10:05:43AM +0100, Jonathan Wakely via Gcc-patches
> wrote:
> > > Looking at assembly, one of the differences I see is that the "after"
> > > version has calls to realloc_insert(), while "before" versi
On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches
wrote:
>
> On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
> >
> >
> > On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> >> Middle-end folks: any thoughts about how best to make
On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches
wrote:
>
>
> C++ requires inline functions to be declared inline and defined in
> every translation unit that uses them. frange_nextafter is used in
> gimple-range-op.cc but it's only defined as inline in
> range-op-float.cc. Drop th
On Thu, Jun 8, 2023 at 7:57 PM Marek Polacek via Gcc-patches
wrote:
>
> The manual is incorrect in saying that the option does not warn
> about designated initializers, which it does in C++. Whether the
> divergence in behavior is desirable is another thing, but let's
> at least make the manual m
On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches
wrote:
>
> So for the attached testcase, we assumed that zero_one_valued_p would
> be the value [0,1] but currently zero_one_valued_p matches also
> signed 1 bit integers.
> This changes that not to match that and fixes the 2 new testcas
On Fri, 9 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > On Fri, 9 Jun 2023, Richard Sandiford wrote:
> >
> >> guojiufu writes:
> >> > Hi,
> >> >
> >> > On 2023-06-09 16:00, Richard Biener wrote:
> >> >> On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >> >>
> >> >>> Hi,
> >> >>>
On Fri, 9 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
> Co-authored-by: Richard Biener
>
> This patch address comments from Richard && Richi and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have targ
On Fri, 9 Jun 2023, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, I guess
> ther
On Fri, Jun 9, 2023 at 11:45 AM Andrew Stubbs wrote:
>
> On 09/06/2023 10:02, Richard Sandiford wrote:
> > Andrew Stubbs writes:
> >> On 07/06/2023 20:42, Richard Sandiford wrote:
> >>> I don't know if this helps (probably not), but we have a similar
> >>> situation on AArch64: a 64-bit mode like
On Fri, 9 Jun 2023, Richard Biener wrote:
> On Fri, 9 Jun 2023, Richard Biener wrote:
>
> > The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> > ICEs when tree checking is enabled. This should avoid wrong-code
> > in cases like PR110182 and instead ICE.
> >
> > Bootstrap and re
On Fri, Jun 9, 2023 at 11:58 AM Lehua Ding wrote:
>
> > It's odd that the checksum doesn't depend on the number of iterations done
> > ...
>
> This is because the difference between the calculated result (32063.902344)
> and
> the expected result (32000.00) is small. The current check is tha
On Fri, Jun 9, 2023 at 2:26 PM Alexandre Oliva wrote:
>
> On Jun 9, 2023, Richard Biener wrote:
>
> > On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches
> > wrote:
>
> >> C++ requires inline functions to be declared inline and defined in
> >> every translation unit that uses them.
On Fri, 9 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >
> >>
> >> Hi,
> >>
> >> Richard Biener writes:
> >>
> >> > On Fri, 9 Jun 2023, Richard Sandiford wrote:
> >> >
> >> >> guojiufu writes:
> >> >> > Hi,
> >> >> >
> >> >> >
On Fri, 9 Jun 2023, Martin Jambor wrote:
> Hi,
>
> thanks for looking at this.
>
> On Fri, Jun 02 2023, Richard Biener wrote:
> > On Mon, 29 May 2023, Martin Jambor wrote:
> >
>
> [...]
>
> >> diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
> >> index 27c84e78fcf..33215b5fc82 100644
On Mon, 12 Jun 2023, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >
> >>
> >> Hi,
> >>
> >> Richard Biener writes:
> >>
> >> > On Fri, 9 Jun 2023, Jiufu Guo wrote:
> >> >
> >> >>
> >> >> Hi,
> >> >>
> >> >> Richard Biener writes:
> >> >>
> >> >>
The following fixes code GENERIC generation for (convert! ...)
which currently generates
if (TREE_TYPE (_o1[0]) != type)
_r1 = fold_build1_loc (loc, NOP_EXPR, type, _o1[0]);
if (EXPR_P (_r1))
goto next_after_fail867;
else
_r1 = _o1[0];
where obviously braces are missing.
Bo
On Mon, 12 Jun 2023, Andre Vieira (lists) wrote:
>
>
> On 05/06/2023 04:04, Jan Hubicka wrote:
> >> On Thu, 1 Jun 2023, Andre Vieira (lists) wrote:
> >>
> >>> Hi,
> >>>
> >>> This is a follow-up of the internal function patch to add widening and
> >>> narrowing patterns. This patch improves the
On Mon, 12 Jun 2023, Tamar Christina wrote:
> 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?
OK.
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config.in: Regenerate
Alias analysis was treating .MASK_STORE as storing a full vector
which means we disambiguate against decls of smaller than vector size.
That's of course wrong and a similar issue was fixed for DSE already.
The following makes sure we set the size of the access to unknown
and only constrain max_size
On Tue, 6 Jun 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch introduces {add,sub}c5_optab and pattern recognizes
> various forms of add with carry and subtract with carry/borrow, see
> pr79173-{1,2,3,4,5,6}.c tests on what is matched.
> Primarily forms with 2 __builtin_add_overflow or _
Alias analysis was treating .MASK_LOAD as storing a full vector
which means we disambiguate against decls of smaller than vector size.
This complements the previous patch handling .MASK_STORE and fixes
runtime execution FAILs of gfortran.dg/matmul_3.f90 and
gfortran.dg/inline_sum_2.f90 when using A
The following fixes native interpretation of a buffer as boolean
vector with bit-precision elements such as AVX512 vectors. The
check whether the buffer covers the whole vector was broken for
bit-precision elements and the following instead implements it
based on the vector type size.
Bootstrappe
On Mon, Jun 12, 2023 at 4:04 PM Roger Sayle wrote:
>
>
> The following simple test case, from PR 104610, shows that memcmp () == 0
> can result in some bizarre code sequences on x86.
>
> int foo(char *a)
> {
> static const char t[] = "0123456789012345678901234567890";
> return __builtin_me
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-loop-ch.cc (ch_base::copy_headers): Free loop BBs.
---
gcc/tree-ssa-loop-ch.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/tree-ssa-loop-ch.cc b/gcc/tree-ssa-loop-ch.cc
index 7fdef3bb11a..22252bee135 100
On Wed, 14 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Segher Boessenkool writes:
>
> > Hi!
> >
> > As I said in a reply to the original patch: not okay. Sorry.
>
> Thanks a lot for your comments!
> I'm also thinking about other solutions:
> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])"
>
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > AFAIU this special instruction is only supposed to prevent
> > code motion (of stack memory accesses?) across this instruction?
> > I'd say a
> >
> > (may_clobber (mem:BLK (reg:DI 1 1)))
> >
> > might be more to the poin
Currently vect_determine_partial_vectors_and_peeling will decide
to apply fully masking to the main loop despite
--param vect-partial-vector-usage=1 when the currently analyzed
vector mode results in a vectorization factor that's bigger
than the number of scalar iterations. That's undesirable fo
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 14 Jun 2023, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > AFAIU this special instruction is only supposed to prevent
> >> > code motion (of stack memory accesses?) across this instruction?
> >>
The function is only meaningful for LOOP_VINFO_MASKS processing so
inline it into the single use.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
* tree-vect-loop.cc (vect_get_max_nscalars_per_iter): Inline
into ...
(vect_verify_full_masking): ... this.
---
gcc/t
This adds a loop_vinfo argument for future use, making the next
patch smaller.
* tree-vectorizer.h (vect_get_loop_mask): Add loop_vec_info
argument.
* tree-vect-loop.cc (vect_get_loop_mask): Likewise.
(vectorize_fold_left_reduction): Adjust.
(vect_transform_
This implemens fully masked vectorization or a masked epilog for
AVX512 style masks which single themselves out by representing
each lane with a single bit and by using integer modes for the mask
(both is much like GCN).
AVX512 is also special in that it doesn't have any instruction
to compute the
On Wed, 14 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 01:29:04PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > > + else if (addc_subc)
> > > > + {
> > > > + if (!integer_zerop (arg2))
> > > > + ;
> > > > + /* x = y + 0 + 0;
On Tue, 13 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 08:40:36AM +, Richard Biener wrote:
> > I suspect re-association can wreck things even more here. I have
> > to say the matching code is very hard to follow, not sure if
> > splitting out a function matching
> >
> >_22 =
1 - 100 of 6045 matches
Mail list logo
