On Wed, Aug 30, 2023 at 3:42 AM Marek Polacek via Gcc-patches
wrote:
>
> Improving the security of software has been a major trend in the recent
> years. Fortunately, GCC offers a wide variety of flags that enable extra
> hardening. These flags aren't enabled by default, though. And since
> the
On Mon, Sep 4, 2023 at 4:57 PM Uros Bizjak wrote:
>
> On Mon, Sep 4, 2023 at 2:28 AM Hongtao Liu wrote:
>
> > > > > > > > I think there should be some constraint which explicitly has
> > > > > > > > all the 32
> > > > > > > > GPRs, like there is one for just all 16 GPRs (h), so that
> > > > > >
On Fri, Sep 1, 2023 at 7:03 PM Richard Sandiford via Gcc-patches
wrote:
>
> Uros Bizjak via Gcc-patches writes:
> > On Thu, Aug 31, 2023 at 11:18 AM Jakub Jelinek via Gcc-patches
> > wrote:
> >>
> >> On Thu, Aug 31, 2023 at 04:20:17PM +0800, Hongyu Wang via Gcc-patches
> >> wrote:
> >> > From:
On Fri, Sep 1, 2023 at 7:27 PM Uros Bizjak wrote:
>
> On Fri, Sep 1, 2023 at 12:36 PM Hongtao Liu wrote:
> >
> > On Fri, Sep 1, 2023 at 5:38 PM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > On Fri, Sep 1, 2023 at 11:10 AM Hongyu Wang
> > > wrote:
> > > >
> > > > Uros Bizjak via Gcc-patche
On Thu, Aug 31, 2023 at 5:31 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 31, 2023 at 11:26 AM Richard Biener
> wrote:
> >
> > On Thu, Aug 31, 2023 at 10:25 AM Hongyu Wang via Gcc-patches
> > wrote:
> > >
> > > From: Kong Lingling
> > >
> > > Disable EGPR usage for below legacy insn
On Fri, Sep 1, 2023 at 5:38 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Fri, Sep 1, 2023 at 11:10 AM Hongyu Wang wrote:
> >
> > Uros Bizjak via Gcc-patches 于2023年8月31日周四 18:01写道：
> > >
> > > On Thu, Aug 31, 2023 at 11:18 AM Jakub Jelinek via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Aug
On Wed, Aug 30, 2023 at 8:18 PM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Aug 30, 2023 at 12:38 PM liuhongt via Gcc-patches
> wrote:
> >
> > r14-332-g24905a4bd1375c adjusts costing of emulated vectorized
> > gather/scatter.
> >
> > commit 24905a4bd1375ccd99c02510b9f9529015a48315
> >
On Thu, Aug 24, 2023 at 5:05 PM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> For PR27, the wrong code was caused by wrong expander for maskz.
> correct the parameter order for avx512ne2ps2bf16_maskz expander
>
> Bootstrapped/regtested on x86-64-pc-linux-gnu{m32,}.
> OK for master and backpor
On Wed, Aug 23, 2023 at 12:31 PM liuhongt wrote:
>
> Both "graniterapid-d" and "graniterapids" are attached with
> PROCESSOR_GRANITERAPID in processor_alias_table but mapped to
> different __cpu_subtype in get_intel_cpu.
>
> And get_builtin_code_for_version will try to match the first
> PROCESSOR_
On Wed, Aug 23, 2023 at 4:08 PM Hongtao Liu wrote:
>
> On Wed, Aug 23, 2023 at 3:02 PM Jonathan Wakely wrote:
> >
> >
> >
> > On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++,
> > wrote:
> >>
> >> On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote:
> >> >
> >> > On Tue, Aug 8, 2023 at 5:22
On Wed, Aug 23, 2023 at 4:31 PM Jakub Jelinek wrote:
>
> On Wed, Aug 23, 2023 at 08:03:58AM +, Jiang, Haochen wrote:
> > We could first work on -mevex512 then further discuss -mavx10.1-256/512
> > since
> > these -mavx10.1-256/512 is quite controversial.
> >
> > Just to clarify, -mno-evex512
On Wed, Aug 23, 2023 at 4:16 PM Jakub Jelinek wrote:
>
> On Wed, Aug 23, 2023 at 01:57:59AM +, Jiang, Haochen wrote:
> > > > Let's assume there's no detla now, AVX10.1-512 is equal to
> > > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPCNTDQ}
> > > > > other stuff.
> > > > >
On Wed, Aug 23, 2023 at 3:33 PM Richard Biener
wrote:
>
> On Tue, Aug 22, 2023 at 4:36 PM Hongtao Liu wrote:
> >
> > On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> > > > Ok, then we can't avoid TARGET_AVX10_1 in tho
On Wed, Aug 23, 2023 at 3:02 PM Jonathan Wakely wrote:
>
>
>
> On Wed, 23 Aug 2023, 06:15 Hongtao Liu via Libstdc++,
> wrote:
>>
>> On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote:
>> >
>> > On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++
>> > wrote:
>> > >
>> > > On Mon, Aug 07,
On Wed, Aug 23, 2023 at 7:28 AM Hongtao Liu wrote:
>
> On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++
> wrote:
> >
> > On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches
> > wrote:
> > > Committed as obvious.
> > >
> > > Less obvious (to me) is whether it's cor
On Wed, Aug 23, 2023 at 9:58 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Tuesday, August 22, 2023 11:02 PM
> > To: Hongtao Liu
> > Cc: Richard Biener ; Jiang, Haochen
> > ; ZiNgA BuRgA ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: Intel AVX10.1 C
On Tue, Aug 8, 2023 at 5:22 AM Marek Polacek via Libstdc++
wrote:
>
> On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches
> wrote:
> > Committed as obvious.
> >
> > Less obvious (to me) is whether it's correct to say "GCC V13" here. I
> > don't think we refer to a version th
On Tue, Aug 22, 2023 at 9:35 PM Hongtao Liu wrote:
>
> On Tue, Aug 22, 2023 at 9:24 PM Richard Biener
> wrote:
> >
> > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > > > > Agreed. And I still think -mevex512 vs.
On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote:
> > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit
> > evex instruction patterns.
>
> Why?
> Internally for md etc. purposes, we should have the current
> TAR
On Tue, Aug 22, 2023 at 9:24 PM Richard Biener
wrote:
>
> On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote:
> >
> > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote:
> > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option
> > > > name to represent whether th
On Tue, Aug 22, 2023 at 4:34 PM Jakub Jelinek wrote:
>
> On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches
> wrote:
> > I think internally we should have conditional 512bit support work across
> > AVX512 and AVX10.
> >
> > I also think it makes sense to _internally_ have AV
On Tue, Aug 22, 2023 at 5:05 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 Mon, Jul 17, 2023 at 5:18 PM Richard Biener via Gcc-patches
wrote:
>
> On Fri, 14 Jul 2023, Jan Hubicka wrote:
>
> > Hi,
> > loop-ch currently does analysis using ranger for all loops to identify
> > candidates and then follows by phase where headers are duplicated (which
> > breaks SSA and ran
On Mon, Aug 21, 2023 at 8:59 PM Richard Biener wrote:
>
> On Mon, 21 Aug 2023, Hongtao Liu wrote:
>
> > 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 afte
On Mon, Aug 21, 2023 at 8:40 PM Hongtao Liu wrote:
>
> 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
> >
>
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
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 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 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 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 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 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 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 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 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: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: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
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 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
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 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 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 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 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 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: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 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 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 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 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 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: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 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 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 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 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 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 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: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: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: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: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: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: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: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: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: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 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 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 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 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 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.
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 ()
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
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
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 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 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 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 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: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: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: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 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 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
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 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
On Tue, Jul 11, 2023 at 11:40 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently on trunk, both usage of intrin and builtin for 128 bit VAES
> ISA will result in ICE since we did not check AVX512VL until pattern,
> which is not user expected. This patch aims to fix that ICE and thro
Please ignore this patch, I'm testing another patch to separate non
swap operands case where a setcc is not needed in the peephole2.
On Tue, Jul 11, 2023 at 11:14 AM liuhongt via Gcc-patches
wrote:
>
> Similar like we did for cmpxchg, but extended to all
> ix86_comparison_int_operator since cmpcc
On Tue, Jul 11, 2023 at 12:24 AM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
>
> > False dependency happens when destination is only updated by
> > pternlog. There is no false dependency when destination is also used
> > in source. So either
On Fri, Jul 7, 2023 at 3:50 PM Hongtao Liu wrote:
>
> On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich wrote:
> >
> > On 07.07.2023 09:46, Hongtao Liu wrote:
> > > On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
> > > wrote:
> > >>
> > >> On 06.07.2023 13:57, haochen.jiang wrote:
> > >>>
On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich wrote:
>
> On 07.07.2023 09:46, Hongtao Liu wrote:
> > On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
> > wrote:
> >>
> >> On 06.07.2023 13:57, haochen.jiang wrote:
> >>> On Linux/x86_64,
> >>>
> >>> e007369c8b67bcabd57c4fed8cff2a6db82e78e
On Fri, Jul 7, 2023 at 3:34 PM Jan Beulich wrote:
>
> On 07.07.2023 09:30, Hongtao Liu wrote:
> > On Fri, Jul 7, 2023 at 3:13 PM Jan Beulich via Gcc-regression
> > wrote:
> >>
> >> On 06.07.2023 13:57, haochen.jiang wrote:
> >>> On Linux/x86_64,
> >>>
> >>> 2d11c99dfca3cc603dbbfafb3afc41689a68e40
On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
wrote:
>
> On 06.07.2023 13:57, haochen.jiang wrote:
> > On Linux/x86_64,
> >
> > e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
> > commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
> > Author: Jan Beulich
> > Date:
On Fri, Jul 7, 2023 at 3:13 PM Jan Beulich via Gcc-regression
wrote:
>
> On 06.07.2023 13:57, haochen.jiang wrote:
> > On Linux/x86_64,
> >
> > 2d11c99dfca3cc603dbbfafb3afc41689a68e40f is the first bad commit
> > commit 2d11c99dfca3cc603dbbfafb3afc41689a68e40f
> > Author: Jan Beulich
> > Date:
On Thu, Jul 6, 2023 at 11:46 PM wrote:
>
> > +; False dependency happens on destination register which is not really
> > +; used when moving all ones to vector register
> > +(define_split
> > + [(set (match_operand:VMOVE 0 "register_operand")
> > + (match_operand:VMOVE 1 "int_float_vector_all
On Fri, Jul 7, 2023 at 2:02 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Fri, Jul 7, 2023 at 7:31 AM liuhongt wrote:
> >
> > > Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> > > and the other emitting UNSPEC_IEEE_MIN.
> > Splitted.
> >
> > > The test involves blendv instr
On Wed, Jul 5, 2023 at 6:22 PM Hongtao Liu wrote:
>
> On Wed, Jul 5, 2023 at 5:03 PM Jan Beulich wrote:
> >
> > On 05.07.2023 10:47, Hongtao Liu wrote:
> > > On Wed, Jul 5, 2023 at 4:01 PM Jan Beulich via Gcc-patches
> > > wrote:
> > >>
> > >> V2TImode values cannot appear in the upper 16 YMM re
On Wed, Jul 5, 2023 at 5:03 PM Jan Beulich wrote:
>
> On 05.07.2023 10:47, Hongtao Liu wrote:
> > On Wed, Jul 5, 2023 at 4:01 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> V2TImode values cannot appear in the upper 16 YMM registers without
> >> AVX512VL being enabled. Therefore forcing 512-
On Wed, Jul 5, 2023 at 4:55 PM Jan Beulich wrote:
>
> On 05.07.2023 10:40, Hongtao Liu wrote:
> > On Wed, Jul 5, 2023 at 4:00 PM Jan Beulich via Gcc-patches
> > wrote:
> >>
> >> The middle alternative each was unusable without enabling AVX512DQ (in
> >> addition to AVX512VL), which is entirely un
1 - 100 of 971 matches
Mail list logo
