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_vec_info stmt_info,
> > >vec &vec_dsts,
> >
On Tue, Jun 6, 2023 at 12:49 PM Andrew Pinski wrote:
>
> On Mon, Jun 5, 2023 at 9:34 PM liuhongt via Gcc-patches
> wrote:
> >
> > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> > TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> > uses ABSU_EXPR + VCE inst
On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
>
> On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
> wrote:
> >
> > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for
> > TYPE_MIN, but PABSB will store unsigned result into dst. The patch
> > uses ABSU_EXPR + VCE instead
On Tue, Jun 6, 2023 at 10:36 PM Uros Bizjak wrote:
>
> On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote:
> >
> > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
> > >
> > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches
> > > wrote:
> > > >
> > > > r14-1145 fold the intrinsics into g
On Wed, Jun 7, 2023 at 8:31 AM Hongtao Liu wrote:
>
> On Tue, Jun 6, 2023 at 10:36 PM Uros Bizjak wrote:
> >
> > On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote:
> > >
> > > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
> > > >
> > > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patche
On Tue, Jun 6, 2023 at 4:23 PM liuhongt wrote:
>
> > I think this is a better patch and will always be correct and still
> > get folded at the gimple level (correctly):
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index d4ff56ee8dd..02bf5ba93a5 100644
> > --- a/gcc/config
On Mon, Jun 5, 2023 at 9:26 AM liuhongt wrote:
>
> This patch only support vec_pack/unpacks optabs for vector modes whose lenth
> >= 128.
> For 32/64-bit vector, they're more hanlded by BB vectorizer with
> truncmn2/extendmn2/fix{,uns}_truncmn2.
>
> Bootstrapped and regtested on x86_64-pc-linux-g
On Wed, Jun 14, 2023 at 1:55 PM Jan Beulich via Gcc-patches
wrote:
>
> Like is already the case for the AVX/AVX2 form, VMOVDDUP - acting on
> double precision floating values - is more appropriate to use here, and
> it can also result in shorter insn encodings when source is memory or
> %xmm0...%x
On Wed, Jun 14, 2023 at 1:56 PM Jan Beulich via Gcc-patches
wrote:
>
> gcc/
>
> * config/i386/constraints.md: Mention k and r for B.
Ok.
>
> --- a/gcc/config/i386/constraints.md
> +++ b/gcc/config/i386/constraints.md
> @@ -162,7 +162,9 @@
> ;; g GOT memory operand.
> ;; m Vector memo
On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
wrote:
>
> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
> never longer (yet sometimes shorter) than the corresponding VSHUFPS /
> VPSHUFD, due to the immediate operand of the shuffle insns balancing the
> need for
On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
wrote:
>
> There's no reason to constrain this to AVX512VL, as the wider operation
> is not usable for more narrow operands only when the possible memory
But this may require more resources (on AMD znver4 processor a zmm
instruction will
On Tue, Jun 13, 2023 at 10:07 AM Kewen Lin via Gcc-patches
wrote:
>
> This patch adjusts the cost handling on
> VMAT_CONTIGUOUS_PERMUTE in function vectorizable_load. We
> don't call function vect_model_load_cost for it any more.
>
> As the affected test case gcc.target/i386/pr70021.c shows,
> th
On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
>
> On 14.06.2023 09:41, Hongtao Liu wrote:
> > On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
> >> never longer (yet sometimes shorter) than
On Wed, Jun 14, 2023 at 5:32 PM Jan Beulich wrote:
>
> On 14.06.2023 10:10, Hongtao Liu wrote:
> > On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> There's no reason to constrain this to AVX512VL, as the wider operation
> >> is not usable for more narrow operands o
On Thu, Jun 15, 2023 at 1:23 PM Hongtao Liu wrote:
>
> On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
> >
> > On 14.06.2023 09:41, Hongtao Liu wrote:
> > > On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> > > wrote:
> > >>
> > >> ... in vec_dupv4sf / *vec_dupv4si. The respective
On Thu, Jun 15, 2023 at 2:41 PM Jan Beulich wrote:
>
> On 15.06.2023 07:23, Hongtao Liu wrote:
> > On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
> >>
> >> On 14.06.2023 09:41, Hongtao Liu wrote:
> >>> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> >>> wrote:
>
> ...
On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
> wrote:
> >
> > The input constraint for the %vmovddup alternative was wrong, as the
> > upper 16 XMM registers require AVX512VL to be used with this insn. To
> > co
On Wed, Jul 12, 2023 at 4:57 AM Roger Sayle wrote:
>
>
> > From: Hongtao Liu
> > Sent: 28 June 2023 04:23
> > > From: Roger Sayle
> > > Sent: 27 June 2023 20:28
> > >
> > > I've also come up with an alternate/complementary/supplementary
> > > fix of generating the PTEST during RTL expansion, rat
ping.
On Mon, May 22, 2023 at 4:08 PM Hongtao Liu wrote:
>
> ping.
>
> On Sat, May 13, 2023 at 5:20 PM liuhongt wrote:
> >
> > > I think this could be simplified if you use either EnumSet or
> > > EnumBitSet instead in common.opt for `-fcf-protection=`.
> >
> > Use EnumSet instead of EnumBitSet
On Wed, Jul 12, 2023 at 9:37 PM Richard Biener via Gcc-patches
wrote:
>
> The PRs ask for optimizing of
>
> _1 = BIT_FIELD_REF ;
> result_4 = BIT_INSERT_EXPR ;
>
> to a vector permutation. The following implements this as
> match.pd pattern, improving code generation on x86_64.
>
> On the RTL
On Thu, Jul 13, 2023 at 10:47 AM Hongtao Liu wrote:
>
> On Wed, Jul 12, 2023 at 9:37 PM Richard Biener via Gcc-patches
> wrote:
> >
> > The PRs ask for optimizing of
> >
> > _1 = BIT_FIELD_REF ;
> > result_4 = BIT_INSERT_EXPR ;
> >
> > to a vector permutation. The following implements this a
On Thu, Jul 13, 2023 at 2:32 PM Richard Biener wrote:
>
> On Thu, 13 Jul 2023, Hongtao Liu wrote:
>
> > On Thu, Jul 13, 2023 at 10:47?AM Hongtao Liu wrote:
> > >
> > > On Wed, Jul 12, 2023 at 9:37?PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > The PRs ask for optimizing of
> > >
On Thu, Jul 13, 2023 at 2:06 PM Haochen Jiang via Gcc-patches
wrote:
>
> From: Kong Lingling
>
> gcc/ChangeLog
>
> * common/config/i386/cpuinfo.h (get_available_features): Detect
> avxvnniint16.
> * common/config/i386/i386-common.cc
> (OPTION_MASK_ISA2_AVXVNNIINT16
On Thu, Jul 13, 2023 at 2:06 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detect SHA512.
> * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SHA512_SET,
> OPTION_MASK_ISA2_SHA512_UNSET)
On Thu, Jul 13, 2023 at 2:04 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detect SM3.
> * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SM3_SET,
> OPTION_MASK_ISA2_SM3_UNSET): New.
>
On Thu, Jul 13, 2023 at 2:04 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detech SM4.
> * common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SM4_SET,
> OPTION_MASK_ISA2_SM4_UNSET): New.
>
On Fri, Jul 14, 2023 at 10:55 AM Mo, Zewei via Gcc-patches
wrote:
>
> Hi all,
>
> This patch is to add initial support for Lunar Lake, Arrow Lake and Arrow Lake
> S for GCC.
>
> This link of related information is listed below:
> https://www.intel.com/content/www/us/en/develop/download/intel-archi
On Fri, Jul 14, 2023 at 5:40 PM Jan Beulich via Gcc-patches
wrote:
>
> Introduce a new alternative permitting all 32 registers to be used as
> source without AVX512VL, by broadcasting to the full 512 bits in that
> case. (The insn would also permit all registers to be used as
> destination, but V2
On Fri, Jul 14, 2023 at 5:42 PM Jan Beulich via Gcc-patches
wrote:
>
> In the (however unlikely) event that no insn can be found for the
> requested mode, using maybe_gen_...() without (really) checking its
> result for being a null rtx would lead to silent bad code generation.
Ok.
>
> gcc/
>
>
On Mon, Jul 17, 2023 at 2:20 PM Jan Beulich wrote:
>
> On 17.07.2023 08:09, Hongtao Liu wrote:
> > On Fri, Jul 14, 2023 at 5:40 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> Introduce a new alternative permitting all 32 registers to be used as
> >> source without AVX512VL, by broadcasting t
Ping.
On Tue, Jul 11, 2023 at 5:16 PM liuhongt via Gcc-patches
wrote:
>
> Similar like we did for CMPXCHG, but extended to all
> ix86_comparison_int_operator since CMPCCXADD set EFLAGS exactly same
> as CMP.
>
> When operand order in CMP insn is same as that in CMPCCXADD,
> CMP insn can be elimin
I'd like to ping for this patch (only patch 1/2, for patch 2/2, I
think that may not be necessary).
On Mon, May 15, 2023 at 9:20 AM Hongtao Liu wrote:
>
> ping.
>
> On Fri, Apr 21, 2023 at 9:55 PM liuhongt wrote:
> >
> > > > + if (!TARGET_SSE2)
> > > > +{
> > > > + if (c_dialect_cxx ()
On Mon, Jul 17, 2023 at 7:38 PM Uros Bizjak wrote:
>
> On Mon, Jul 17, 2023 at 10:28 AM Hongtao Liu wrote:
> >
> > I'd like to ping for this patch (only patch 1/2, for patch 2/2, I
> > think that may not be necessary).
> >
> > On Mon, May 15, 2023 at 9:20 AM Hongtao Liu wrote:
> > >
> > > ping.
On Wed, Jul 12, 2023 at 3:27 PM Hongtao Liu wrote:
>
> ping.
>
> On Mon, May 22, 2023 at 4:08 PM Hongtao Liu wrote:
> >
> > ping.
> >
> > On Sat, May 13, 2023 at 5:20 PM liuhongt wrote:
> > >
> > > > I think this could be simplified if you use either EnumSet or
> > > > EnumBitSet instead in comm
On Thu, Jul 20, 2023 at 4:11 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Jul 20, 2023 at 9:35 AM liuhongt wrote:
> >
> > For Intel processors, after TARGET_AVX, vmovdqu is optimized as fast
> > as vlddqu, UNSPEC_LDDQU can be removed to enable more optimizations.
> > Can someone confirm this
On Sat, Jul 29, 2023 at 11:55 AM haochen.jiang via Gcc-regression
wrote:
>
> On Linux/x86_64,
>
> b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb is the first bad commit
> commit b9d7140c80bd3c7355b8291bb46f0895dcd8c3cb
> Author: Jan Hubicka
> Date: Fri Jul 28 09:16:09 2023 +0200
>
> loop-split im
On Fri, Jul 1, 2022 at 2:42 AM Roger Sayle wrote:
>
>
> This patch is a follow-up to Hongtao's fix for PR target/105854. That
> fix is perfectly correct, but the thing that caught my eye was why is
> the compiler generating a shift by zero at all. Digging deeper it
> turns out that we can easily
I think this can be taken as an obvious fix without prior approval.
"Obvious fixes can be committed without prior approval. Just check in
the fix and copy it to gcc-patches."
Quoted from https://gcc.gnu.org/gitwrite.html
On Fri, Jul 1, 2022 at 10:02 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi
On Fri, Jul 1, 2022 at 10:12 AM Hongtao Liu wrote:
>
> On Fri, Jul 1, 2022 at 2:42 AM Roger Sayle wrote:
> >
> >
> > This patch is a follow-up to Hongtao's fix for PR target/105854. That
> > fix is perfectly correct, but the thing that caught my eye was why is
> > the compiler generating a shift
On Tue, Jul 5, 2022 at 1:48 AM Roger Sayle wrote:
>
>
> Hi Hongtao,
> Many thanks for your review. This revised patch implements your
> suggestions of removing the combine splitters, and instead reusing
> the functionality of the ssse3_palignrdi define_insn_and split.
>
> This revised patch has b
On Mon, Jul 11, 2022 at 7:47 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Jul 11, 2022 at 5:44 AM liuhongt wrote:
> >
> > The patch only handles load/store(including ctor/permutation, except
> > gather/scatter) for complex type, other operations don't needs to be
> > handled since they wi
On Mon, Jul 11, 2022 at 4:03 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Mon, Jul 11, 2022 at 3:15 AM liuhongt wrote:
> >
> > And split it to GPR-version instruction after reload.
> >
> > This will enable below optimization for 16/32/64-bit vector bit_op
> >
> > - movd(%rdi), %xmm0
> >
On Tue, Jul 12, 2022 at 10:12 PM Richard Biener
wrote:
>
> On Tue, Jul 12, 2022 at 6:11 AM Hongtao Liu wrote:
> >
> > On Mon, Jul 11, 2022 at 7:47 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Mon, Jul 11, 2022 at 5:44 AM liuhongt wrote:
> > > >
> > > > The patch only handles load
On Thu, Jul 14, 2022 at 4:20 PM Richard Biener
wrote:
>
> On Wed, Jul 13, 2022 at 9:34 AM Richard Biener
> wrote:
> >
> > On Wed, Jul 13, 2022 at 6:47 AM Hongtao Liu wrote:
> > >
> > > On Tue, Jul 12, 2022 at 10:12 PM Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 6:11 AM H
On Thu, Jul 14, 2022 at 4:53 PM Hongtao Liu wrote:
>
> On Thu, Jul 14, 2022 at 4:20 PM Richard Biener
> wrote:
> >
> > On Wed, Jul 13, 2022 at 9:34 AM Richard Biener
> > wrote:
> > >
> > > On Wed, Jul 13, 2022 at 6:47 AM Hongtao Liu wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 10:12 PM Richar
On Thu, Jul 14, 2022 at 3:22 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Jul 14, 2022 at 7:33 AM liuhongt wrote:
> >
> > And split it to GPR-version instruction after reload.
> >
> > > ?r was introduced under the assumption that we want vector values
> > > mostly in vector registers. Curren
On Thu, Jul 14, 2022 at 2:11 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> The patch is to fix _mm_[u]comixx_{ss,sd} codegen and add PF result. These
> intrinsics have changed over time, like `_mm_comieq_ss ` old operation is
> `RETURN ( a[31:0] == b[31:0] ) ? 1 : 0`, and new operation u
On Fri, Jul 15, 2022 at 1:44 AM H.J. Lu via Gcc-patches
wrote:
>
> When shadow stack is enabled, function with indirect_return attribute
> may return via indirect jump. In this case, we need to disable sibcall
> if caller doesn't have indirect_return attribute and indirect branch
> tracking is en
On Sat, Jul 16, 2022 at 10:08 PM Roger Sayle wrote:
>
>
> This AVX512 specific patch to sse.md is split out from an earlier patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596199.html
>
> The new splitters proposed in that patch interfere with AVX512's
> kunpckdq instruction which is
On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Tue, Jul 19, 2022 at 8:07 AM liuhongt wrote:
> >
> > And split it after reload.
> >
> > > You will need ix86_binary_operator_ok insn constraint here with
> > > corresponding expander using ix86_fixup_binary_operands_no_copy
On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
>
> On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
> >
> > On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > On Tue, Jul 19, 2022 at 8:07 AM liuhongt wrote:
> > > >
> > > > And split it after reload.
> > > >
On Wed, Jul 20, 2022 at 2:18 PM Uros Bizjak wrote:
>
> On Wed, Jul 20, 2022 at 8:14 AM Uros Bizjak wrote:
> >
> > On Wed, Jul 20, 2022 at 4:37 AM Hongtao Liu wrote:
> > >
> > > On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
> > > >
> > > > On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
On Wed, Jul 20, 2022 at 3:18 PM Uros Bizjak wrote:
>
> On Wed, Jul 20, 2022 at 8:54 AM Hongtao Liu wrote:
> >
> > On Wed, Jul 20, 2022 at 2:18 PM Uros Bizjak wrote:
> > >
> > > On Wed, Jul 20, 2022 at 8:14 AM Uros Bizjak wrote:
> > > >
> > > > On Wed, Jul 20, 2022 at 4:37 AM Hongtao Liu wrote:
On Wed, Jul 20, 2022 at 4:00 PM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Jul 20, 2022 at 4:46 AM liuhongt wrote:
> >
> > > My original comments still stand (it feels like this should be more
> > > generic).
> > > Can we go the way lowering complex loads/stores first? A large part
> > >
On Wed, Jul 20, 2022 at 3:59 PM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Jul 20, 2022 at 4:20 AM liuhongt wrote:
> >
> > __builtin_cexpi can't be vectorized since there's gap between it and
> > vectorized sincos version(In libmvec, it passes a double and two
> > double pointer and return
On Wed, Aug 3, 2022 at 4:41 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> Old patch has some mistake in `*movbf_internal` , now disable BFmode constant
> double move in `*movbf_internal`.
LGTM.
>
> Thanks,
> Lingling
>
> > -Original Message-
> > From: Kong, Lingling
> > Sent: Tues
On Thu, Aug 4, 2022 at 4:19 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 4, 2022 at 6:29 AM liuhongt via Gcc-patches
> wrote:
> >
> > For neg, the patch create a vec_init as [ a, -a, a, -a, ... ] and no
> > vec_step is needed to update vectorized iv since vf is always multiple
> > of
On Fri, Aug 4, 2023 at 1:30 AM Alexander Monakov wrote:
>
>
> On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote:
>
> > > +;; If the first and the second operands of ternlog are invariant and ;;
> > > +the third operand is memory ;; then we should add load third operand
> > > +from memory to
On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches
wrote:
>
> Drop SSE5 leftovers from both its comment and its default calculation.
> A value of 2 simply cannot occur anymore. Instead extend the comment to
> mention the use of the attribute in "length_vex", clarifying why
> "prefix_extra"
On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches
wrote:
>
> Record common properties in other attributes' default calculations:
> There's always a 1-byte immediate, and they're always encoded in a VEX3-
> like manner (note that "prefix_extra" already evaluates to 1 in this
> case). The d
On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches
wrote:
>
> They're all VEX3- (also covering XOP) or EVEX-encoded. Express that in
> the default calculation of "prefix". FMA4 insns also all have a 1-byte
> immediate operand.
>
> Where the default calculation is not sufficient / applicabl
On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches
wrote:
>
> In the rdrand and rdseed cases "prefix_0f" is meant instead. For
> mmx_floatv2siv2sf2 1 is correct only for the first alternative. For
> the integer min/max cases 1 uniformly applies to legacy and VEX
> encodings (the UB and SW
On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches
wrote:
>
> While the attribute is relevant for legacy- and VEX-encoded insns, it is
> of no relevance for EVEX-encoded ones.
>
> While there in avx512dq_broadcast_1 add
> the missing "length_immediate".
Ok.
>
> gcc/
>
> * config/i3
On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches
wrote:
>
> In the three remaining instances separate "prefix_0f" and "prefix_rep"
> are what is wanted instead.
Ok.
>
> gcc/
>
> * config/i386/i386.md (rdbase): Add "prefix_0f" and
> "prefix_rep". Drop "prefix_extra".
>
On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches
wrote:
>
> When first added explicitly in 3ddffba914b2 ("i386.md
> (sse4_1_round2): Add avx512f alternative"), "*" should not have
> been used for the pre-existing alternative. The attribute was plain
> missing. Subsequent changes adding m
On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches
wrote:
>
> Many were lacking "prefix" and "prefix_extra", some had a bogus value of
> 2 for "prefix_extra" (presumably inherited from their SSE5 counterparts,
> which are long gone) and a meaningless "prefix_data16" one. Where
> missing, "
On Thu, Aug 3, 2023 at 4:17 PM Jan Beulich via Gcc-patches
wrote:
>
> The attribute defaults to 1 for TI-mode insns of type sselog, sselog1,
> sseiadd, sseimul, and sseishft.
>
> In *v8hi3 [smaxmin] and *v16qi3 [umaxmin] also drop the
> similarly stray "prefix_extra" at this occasion. These two ma
On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches
wrote:
>
> gcc/
>
> * config/i386/sse.md
> (__): Add
> "prefix" attribute.
>
> (avx512fp16_sh_v8hf):
> Likewise.
Ok.
> ---
> Talking of "prefix": Shouldn't at least V32HF and V32BF have it also
> de
On Thu, Aug 3, 2023 at 4:09 PM Jan Beulich via Gcc-patches
wrote:
>
> Having noticed various bogus uses, I thought I'd go through and audit
> them all. This is the result, with some other attributes also adjusted
> as noticed in the process. (I think this tidying also is a good thing
> to have ahe
On Mon, Aug 7, 2023 at 5:19 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Mon, Aug 7, 2023 at 10:57 AM liuhongt wrote:
> >
> > Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/Chan
On Mon, Aug 7, 2023 at 4:54 PM liuhongt wrote:
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
> In function ‘matmul_i1_avx512f’:
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.
On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
>
> Do you have any comments on the interaction of AVX10 with the
> micro-architecture levels defined in the ABI (and supported with
> glibc-hwcaps directories in glibc)? Given that the levels are cumulative,
> should we take it that any future l
On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches
> wrote:
> >
> > Hi Jakub,
> >
> > > So, what does this imply for the current ISAs?
> >
> > AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an
>
On Wed, Aug 9, 2023 at 10:06 AM Hongtao Liu wrote:
>
> On Tue, Aug 8, 2023 at 8:45 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches
> > wrote:
> > >
> > > Hi Jakub,
> > >
> > > > So, what does this imply for the current ISAs?
> > >
On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
>
> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
> >
> > Do you have any comments on the interaction of AVX10 with the
> > micro-architecture levels defined in the ABI (and supported with
> > glibc-hwcaps directories in glibc)? Given that t
On Wed, Aug 9, 2023 at 10:14 AM Hongtao Liu wrote:
>
> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
> >
> > On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
> > >
> > > Do you have any comments on the interaction of AVX10 with the
> > > micro-architecture levels defined in the ABI (and su
On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>
> On 09.08.2023 04:14, Hongtao Liu wrote:
> > On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
> >>
> >> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
> >> wrote:
> >>>
> >>> Do you have any comments on the interaction of AVX10 with the
> >>> m
On Wed, Aug 9, 2023 at 4:14 PM Florian Weimer wrote:
>
> * Richard Biener via Gcc-patches:
>
> > I don’t think we can realistically change the ABI. If we could
> > passing them in two 256bit registers would be possible as well.
> >
> > Note I fully expect intel to turn around and implement 512 bi
On Wed, Aug 9, 2023 at 5:15 PM Florian Weimer wrote:
>
> * Hongtao Liu:
>
> > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
> >> Aiui these ABI levels were intended to be incremental, i.e. higher versions
> >> would include everything earlier ones cover. Without such a guarantee, how
> >> wou
On Thu, Aug 10, 2023 at 2:01 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Aug 10, 2023 at 2:49 AM liuhongt wrote:
> >
> > Also add ix86_partial_vec_fp_math to to condition of V2HF/V4HF named
> > patterns in order to avoid generation of partial vector V8HFmode
> > trapping instructions.
> >
>
On Thu, Aug 10, 2023 at 2:04 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, Aug 10, 2023 at 3:13 AM liuhongt wrote:
> >
> > Currently we have 3 different independent tunes for gather
> > "use_gather,use_gather_2parts,use_gather_4parts",
> > similar for scatter, there're
> > "use_scatter,use_sc
On Thu, Aug 10, 2023 at 2:06 PM Hongtao Liu wrote:
>
> On Thu, Aug 10, 2023 at 2:01 PM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Thu, Aug 10, 2023 at 2:49 AM liuhongt wrote:
> > >
> > > Also add ix86_partial_vec_fp_math to to condition of V2HF/V4HF named
> > > patterns in order to avoid ge
On Thu, Aug 10, 2023 at 3:49 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 10, 2023 at 9:42 AM Uros Bizjak wrote:
> >
> > On Thu, Aug 10, 2023 at 9:40 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Aug 10, 2023 at 3:13 AM liuhongt wrote:
> > > >
> > > > Currently we have 3 differen
On Thu, Aug 10, 2023 at 3:55 PM Hongtao Liu wrote:
>
> On Thu, Aug 10, 2023 at 3:49 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Aug 10, 2023 at 9:42 AM Uros Bizjak wrote:
> > >
> > > On Thu, Aug 10, 2023 at 9:40 AM Richard Biener
> > > wrote:
> > > >
> > > > On Thu, Aug 10, 2023
On Thu, Aug 10, 2023 at 4:07 PM Hongtao Liu wrote:
>
> On Thu, Aug 10, 2023 at 3:55 PM Hongtao Liu wrote:
> >
> > On Thu, Aug 10, 2023 at 3:49 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Thu, Aug 10, 2023 at 9:42 AM Uros Bizjak wrote:
> > > >
> > > > On Thu, Aug 10, 2023 at 9:40
On Thu, Aug 10, 2023 at 7:13 PM Richard Biener
wrote:
>
> On Thu, Aug 10, 2023 at 11:16 AM Hongtao Liu wrote:
> >
> > On Thu, Aug 10, 2023 at 4:07 PM Hongtao Liu wrote:
> > >
> > > On Thu, Aug 10, 2023 at 3:55 PM Hongtao Liu wrote:
> > > >
> > > > On Thu, Aug 10, 2023 at 3:49 PM Richard Biener
On Fri, Aug 11, 2023 at 2:02 PM liuhongt via Gcc-patches
wrote:
>
> Rename original use_gather to use_gather_8parts, Support
> -mtune-ctrl={,^}use_gather to set/clear tune features
> use_gather_{2parts, 4parts, 8parts}. Support the new option -mgather
> as alias of -mtune-ctrl=, use_gather, ^use_g
cc
On Mon, Aug 14, 2023 at 10:46 AM liuhongt wrote:
>
> vmovapd can enable register renaming and have same code size as
> vmovsd. Similar for vmovsh vs vmovaps, vmovaps is 1 byte less than
> vmovsh.
>
> When TARGET_AVX512VL is not available, still generate
> vmovsd/vmovss/vmovsh to avoid vmovapd/
On Tue, Aug 8, 2023 at 3:16 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Add avx10_set and version and detect avx10.1.
> (cpu_indicator_init): Handle avx10.1-512.
> * common/config/i386/i38
On Tue, Aug 8, 2023 at 3:15 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * config/i386/driver-i386.cc (host_detect_local_cpu):
> Do not append -mno-avx10.1 for -march=native.
> * config/i386/i386-options.cc
> (ix86_check_avx10): New function to che
On Tue, Aug 8, 2023 at 3:13 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * config/i386/driver-i386.cc (host_detect_local_cpu):
> Do not append -mno-avx10-max-512bit for -march=native.
> * common/config/i386/i386-common.cc
> (ix86_check_avx10_vector
On Tue, Aug 8, 2023 at 3:23 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx10_1-vextractf64x2-1.c: New test.
> * gcc.target/i386/avx10_1-vextracti64x2-1.c: Ditto.
> * gcc.target/i386/avx10_1-vfpclasspd-1.c: Ditto.
> * g
On Fri, Aug 11, 2023 at 8:38 AM liuhongt wrote:
>
> For more details of GDS (Gather Data Sampling), refer to
> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html
>
> After microcode update, there's performance
On Mon, Aug 14, 2023 at 10:40 AM Hongtao Liu wrote:
>
> On Fri, Aug 11, 2023 at 2:02 PM liuhongt via Gcc-patches
> wrote:
> >
> > Rename original use_gather to use_gather_8parts, Support
> > -mtune-ctrl={,^}use_gather to set/clear tune features
> > use_gather_{2parts, 4parts, 8parts}. Support the
On Fri, Aug 18, 2023 at 2:01 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to fix PR111051, which actually make sure that AVX2
> intrins are visible to AVX512/AVX10 intrins under any circumstances.
>
> I will also apply the same fix on AVX512DQ scalar intrins.
>
> Regtest
On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
wrote:
>
> Hi,
>
> With the proposed design of these switches, how would I restrict AVX10.1
> to particular AVX-512 subsets?
We can't, avx10.1 is taken as an indivisible ISA which contains all
AVX512 related instructions.
> We’ve been ta
On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
>
> On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > With the proposed design of these switches
On Mon, Aug 21, 2023 at 4:38 PM Jakub Jelinek wrote:
>
> On Mon, Aug 21, 2023 at 04:28:20PM +0800, Hongtao Liu wrote:
> > We have an undocumented option mavx10-max-512bit.
>
> How it is called internally is one thing, but it is weird to use
> avx10 in an option name which would be meant for findin
On Mon, Aug 21, 2023 at 5:35 PM Richard Biener
wrote:
>
> On Mon, Aug 21, 2023 at 10:28 AM Hongtao Liu wrote:
> >
> > On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches
> > > wrote:
> > > > > On Sun, Aug 20,
On Mon, Aug 21, 2023 at 8:25 PM Richard Biener via Gcc-patches
wrote:
>
> The following fixes the gcc.target/i386/pr87007-5.c testcase which
> changed code generation again after the recent sinking improvements.
> We now have
>
> vxorps %xmm0, %xmm0, %xmm0
> vsqrtsd d2(%rip), %xmm
1 - 100 of 971 matches
Mail list logo
