On Thu, May 23, 2024 at 7:53 PM Evgeny Karpov
wrote:
>
>
> Thursday, May 23, 2024 10:35 AM
> Uros Bizjak wrote:
>
> > Richard Sandiford wrote:
> > >
> > > > This looks good to me apart from a couple of very minor comments
> > > > below, bu
On Thu, May 23, 2024 at 10:35 AM Uros Bizjak wrote:
>
> On Wed, May 22, 2024 at 4:32 PM Evgeny Karpov
> wrote:
> >
> > Wednesday, May 22, 2024 1:06 PM
> > Richard Sandiford wrote:
> >
> > > This looks good to me apart from a couple of very minor c
On Wed, May 22, 2024 at 4:32 PM Evgeny Karpov
wrote:
>
> Wednesday, May 22, 2024 1:06 PM
> Richard Sandiford wrote:
>
> > This looks good to me apart from a couple of very minor comments below, but
> > please get approval from the x86 maintainers as well. In particular, they
> > might
> >
On Wed, May 22, 2024 at 5:15 PM Roger Sayle wrote:
>
> This single line patch fixes a strange quirk/glitch in i386's rtx_costs,
> which considers an instruction loading a 64-bit constant to be significantly
> cheaper than loading a 32-bit (or smaller) constant.
>
> Consider the two functions:
>
On Wed, May 22, 2024 at 10:29 AM Kong, Lingling wrote:
>
> > I wonder if we can use "define_subst" to conditionally add flags clobber
> > for !TARGET_APX_NF targets. Even the example for "Define Subst" uses the
> > insn
> > w/ and w/o the clobber, so I think it is worth considering this
On Tue, May 21, 2024 at 11:01 AM Haochen Jiang wrote:
>
> Hi all,
>
> This is the v3 patch to fix PR115069. The new testcase has passed.
>
> Changes in v3:
> - Simplify the testcase.
>
> Changes in v2:
> - Add a testcase.
> - Change the comment for the early exit.
>
> Thx,
> Haochen
>
>
On Tue, May 21, 2024 at 7:13 AM liuhongt wrote:
>
> For CONST_VECTOR_DUPLICATE_P in constant_pool, it is just broadcast or
> variants in ix86_vector_duplicate_simode_const.
> Adjust the cost to COSTS_N_INSNS (2) + speed which should be a little
> bit larger than broadcast.
>
> Bootstrapped and
On Tue, May 21, 2024 at 8:16 AM Haochen Jiang wrote:
>
> Hi all,
>
> Since vpermq is really slow, we should avoid using it when it is
> the only instruction could be used for ix86_expand_vecop_qihi2.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu. Ok for trunk?
>
> Thx,
> Haochen
>
>
Rename _3 expander to a standard ssadd,
usadd, sssub and ussub name to enable corresponding optab expansion.
Also add named expander for MMX modes.
PR middle-end/112600
gcc/ChangeLog:
* config/i386/mmx.md (3): New expander.
* config/i386/sse.md
(_3):
Rename expander to 3.
On Wed, May 15, 2024 at 12:05 PM liuhongt wrote:
>
> pshufb is available under TARGET_SSSE3, so
> ix86_expand_vec_perm_const_1 must return true when TARGET_SSSE3.
> w/o TARGET_SSSE3, if we set one_operand_p to true,
> ix86_expand_vec_perm_const_1 could return false.
>
> With the patch under
On Wed, May 15, 2024 at 9:43 AM Kong, Lingling wrote:
>
> From: Hongyu Wang
>
> APX NF(no flags) feature implements suppresses the update of status flags for
> arithmetic operations.
>
> For NF add, it is not clear whether NF add can be faster than lea. If so, the
> pattern needs to be
On Wed, May 15, 2024 at 9:43 AM Kong, Lingling wrote:
>
> From: Hongyu Wang
>
> APX NF(no flags) feature implements suppresses the update of status flags for
> arithmetic operations.
>
> For NF add, it is not clear whether NF add can be faster than lea. If so, the
> pattern needs to be
On Thu, May 9, 2024 at 11:12 AM Levy Hsu wrote:
>
> Hi All
>
> We've introduced a new subroutine in ix86_expand_vec_perm_const_1
> to optimize vector shifting for the V16QI type on x86.
> This patch uses a three-instruction sequence psrlw, psllw, and por
> to handle specific vector shuffle
On Wed, May 8, 2024 at 4:44 AM Levy Hsu wrote:
>
> PR target/107563
>
> gcc/ChangeLog:
>
> * config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por): New
> subroutine.
> (ix86_expand_vec_perm_const_1): New Entry.
>
> gcc/testsuite/ChangeLog:
>
> *
On Mon, May 6, 2024 at 5:20 AM Hongtao Liu wrote:
>
> CC uros.
>
> On Mon, May 6, 2024 at 11:03 AM Kong, Lingling
> wrote:
> >
> > Hi,
> > (if_then_else:SI (eq (reg:CCZ 17 flags)
> > (const_int 0 [0]))
> > (reg/v:SI 101 [ e ])
> > (reg:SI 102))
> > The cost is 8 for the rtx, the
On Sun, Apr 28, 2024 at 7:47 AM liuhongt wrote:
>
> So when both source operand and dest operand require avx512 MASK_REGS, RA
> can allocate MASK_REGS register instead of GPR to avoid reload it from
> GPR to MASK_REGS.
> It's similar as what did for logic patterns.
>
> Bootstrapped and regtested
On Fri, Apr 26, 2024 at 11:03 AM Haochen Jiang wrote:
>
> Hi all,
>
> The array index should not be over 8 for v8hi, or it will fail
> under -O0 or using -fstack-protector.
>
> This patch aims to fix that, which is mentioned in PR110621.
>
> Commit as obvious and backport to GCC13.
>
> Thx,
>
On Tue, Apr 23, 2024 at 5:50 PM Jakub Jelinek wrote:
>
> Hi!
>
> As discussed in the PR, on ia32 with its 8 GPRs, where 1 is always fixed
> and other 2 often are as well having an alternative which needs 3
> double-word registers is just too much for RA.
> The following patch splits that
On Tue, Apr 16, 2024 at 5:52 AM Alexandre Oliva wrote:
>
>
> Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
> because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
> declared.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86-
On Tue, Apr 16, 2024 at 5:51 AM Alexandre Oliva wrote:
>
>
> A few x86 tests get unexpected insn counts if the toolchain is
> configured with --enable-frame-pointer. Add explicit
> -fomit-frame-pointer so that the expected insn sequences are output.
>
> Regstrapped on x86_64-linux-gnu. Also
On Thu, Apr 11, 2024 at 4:02 PM Segher Boessenkool
wrote:
>
> On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
> > On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> > wrote:
> > > This is never okay. You cannot commit a patch without approval, *eve
On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
wrote:
>
> On Sun, Apr 07, 2024 at 08:31:38AM +0200, Uros Bizjak wrote:
> > If there are no further comments, I plan to commit the referred patch
> > to the mainline on Wednesday. The latest version can be considered an
On Mon, Apr 1, 2024 at 9:28 PM Uros Bizjak wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html
> PR112560 P1 patch.
If there are no further comments, I plan to commit the referred patch
to the mainline on Wednesday. The latest ve
On Fri, Apr 5, 2024 at 5:56 PM H.J. Lu wrote:
>
> Don't use implicit shift count in double-precision shifts in AT syntax
> since they aren't in Intel SDM. Keep the 's' modifier for backward
> compatibility with inline asm statements.
>
> PR target/114590
> * config/i386/i386.md
On Thu, Apr 4, 2024 at 5:08 PM H.J. Lu wrote:
>
> Define __APX_F__ when APX is enabled.
>
> gcc/
>
> PR target/114587
> * config/i386/i386-c.cc (ix86_target_macros_internal): Define
> __APX_F__ when APX is enabled.
>
> gcc/testsuite/
>
> PR target/114587
>
Hello!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html
PR112560 P1 patch.
Thanks,
Uros.
On Wed, Mar 27, 2024 at 11:48 AM Jakub Jelinek wrote:
>
> Hi!
>
> These tests FAIL for quite a while on i686-linux since July last year,
> likely r14-2628 . Since that patch gcc claims _Float16 and __bf16
> support even without -msse2 because some functions could be using
> target attribute.
>
On Thu, Mar 21, 2024 at 10:26 AM Rainer Orth
wrote:
>
> Two avx512cd tests FAIL to assemble with the Solaris/x86 assembler:
>
> FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed
> to produce
Recent PR111822 fix implemented REG_EH_REGION note copying to a STV converted
preload instruction in general_scalar_chain::convert_op. However, the same
issue remains in timode_scalar_chain::convert_op. Instead of copying the
newly introduced code to timode_scalar_chain::convert_op, the patch
On Mon, Mar 18, 2024 at 3:51 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 11:46:54PM +0100, Uros Bizjak wrote:
> > > Can't you just describe the dataflow then, without an unspec? An unspec
> > > by definition does some (unspecified) operation on the
On Mon, Mar 18, 2024 at 3:46 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 11:27:28PM +0100, Uros Bizjak wrote:
> > On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote:
> > > > > (unspec:DI [
> > > > > (reg:C
On Mon, Mar 18, 2024 at 11:52 AM liuhongt wrote:
>
> Commit r14-9459-g618e34d56cc38e only handles
> general_scalar_chain::convert_op. The patch also handles
> timode_scalar_chain::convert_op to avoid potential similar bug.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for
On Fri, Mar 15, 2024 at 9:50 AM Jakub Jelinek wrote:
>
> Hi!
>
> In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
> comparison against CONST_VECTOR. As the comments say:
> /* x <= cst can be handled as x < cst + 1 unless there is
> wrap around in cst + 1.
On Thu, Mar 14, 2024 at 8:42 AM Uros Bizjak wrote:
>
> On Thu, Mar 14, 2024 at 8:32 AM Hongtao Liu wrote:
> >
> > On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote:
> > >
> > > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote:
> > > >
> > &g
On Thu, Mar 14, 2024 at 8:32 AM Hongtao Liu wrote:
>
> On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote:
> >
> > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote:
> > >
> > > When we split
> > > (insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
> > &
On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote:
>
> When we split
> (insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
> (mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct
> SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84
> {*movdi_internal}
>
Forgot to CC gcc-patches@ ML... sorry for the duplicate...
The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'E' (rtx unspec) in try_combine, at combine.cc:3237
This is
3236 /* Just
On Thu, Mar 7, 2024 at 11:29 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote:
> > On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> > wrote:
> > > > but can be something else, such as the above not
On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote:
>
> On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> wrote:
> >
> > On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
> >
> > [snip]
> >
> > > The part we want to fix deals with the
On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
>
> [snip]
>
> > The part we want to fix deals with the *user* of the CC register. It
> > is not true that this is always COMPARISON_P, so EQ, NE,
On Thu, Mar 7, 2024 at 10:04 PM Uros Bizjak wrote:
> The source code that deals with the *user* of the CC register assumes
> the former form, so it blindly tries to update the mode of the CC
> register inside LT comparison RTX (some other nearby source code even
> checks for (cons
On Thu, Mar 7, 2024 at 6:39 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 10:55:12AM +0100, Richard Biener wrote:
> > On Thu, 7 Mar 2024, Uros Bizjak wrote:
> > > This is
> > >
> > > 3236 /* Just replace the CC reg with a new mode.
On Thu, Mar 7, 2024 at 12:11 PM Richard Biener wrote:
>
> On Thu, 7 Mar 2024, Jakub Jelinek wrote:
>
> > On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > >
On Thu, Mar 7, 2024 at 11:37 AM Jakub Jelinek wrote:
>
> On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > The following might also fix the issue and preserve more of th
On Thu, Mar 7, 2024 at 10:56 AM Richard Biener wrote:
>
> On Thu, 7 Mar 2024, Uros Bizjak wrote:
>
> > The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
> >
> > internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> > hav
The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'E' (rtx unspec) in try_combine, at combine.cc:3237
This is
3236 /* Just replace the CC reg with a new mode. */
3237 SUBST
optimize_function_for_size_p predicate is not stable during optab selection,
because it also depends on node->count/node->frequency of the current function,
which are updated during IPA, so they may change between early opts and
late opts. Use optimize_size instead - optimize_size implies
Eliminate common code from x86_32 TARGET_MACHO part in ix86_expand_move and
use generic code instead.
No functional changes.
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_move) [TARGET_MACHO]:
Eliminate common code and use generic code instead.
Bootstrapped and regression
On Wed, Mar 6, 2024 at 9:10 AM Jakub Jelinek wrote:
>
> Hi!
>
> When writing the rest_of_handle_insert_vzeroupper workaround to manually
> remove all the REG_DEAD/REG_UNUSED notes from the IL, I've missed that
> there is a df_analyze () call right after it and that the problems added
> earlier in
On Mon, Mar 4, 2024 at 9:41 AM Jakub Jelinek wrote:
>
> On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote:
> > > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989
> > > +0100
> > > +++ gcc/config/i386/i386-expand.cc 2024-03-0
On Mon, Mar 4, 2024 at 9:25 AM Jakub Jelinek wrote:
>
> Hi!
>
> The Intel extended format has the various weird number categories,
> pseudo denormals, pseudo infinities, pseudo NaNs and unnormals.
> Those are not representable in the GCC real_value and so neither
> GIMPLE nor RTX
umuldi3_highpart expander does:
if (REG_P (operands[2]))
operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]);
on register_operand predicate, which also allows SUBREG RTX. So,
subregs were emitted without ZERO_EXTEND RTX.
But nowadays we have UMUL_HIGHPART that allows us to fix this
Also handle V2BF mode.
PR target/113871
gcc/ChangeLog:
* config/i386/mmx.md (V248FI): Add V2BF mode.
(V24FI_32): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr113871-5a.c: New test.
* gcc.target/i386/pr113871-5b.c: New test.
Bootstrapped and regression tested on
On Mon, Feb 26, 2024 at 10:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> I'd like to ping 2 patches:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645326.html
> i386: Enable _BitInt support on ia32
>
> all the FAILs mentioned in that mail have been fixed by now.
LGTM, based on HJ's advice.
On Sun, Feb 25, 2024 at 10:14 PM H.J. Lu wrote:
>
> ix86_set_func_type checks noreturn attribute to avoid incompatible
> attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
> is set also for _Noreturn without noreturn attribute, check interrupt
> attribute for interrupt
On Sun, Feb 25, 2024 at 5:01 PM H.J. Lu wrote:
>
> ix86_set_func_type checks noreturn attribute to avoid incompatible
> attribute error in LTO1 on interrupt functions. Since TREE_THIS_VOLATILE
> is set also for _Noreturn without noreturn attribute, check interrupt
> attribute for interrupt
On Fri, Feb 23, 2024 at 3:45 AM H.J. Lu wrote:
>
> On Thu, Feb 22, 2024 at 6:39 PM Hongtao Liu wrote:
> >
> > On Thu, Feb 22, 2024 at 10:33 PM H.J. Lu wrote:
> > >
> > > On Sun, Feb 18, 2024 at 8:02 AM H.J. Lu wrote:
> > > >
> > > > If assembler and linker supports
> > > >
> > > > add %reg1,
A compile-time test can use -march=skylake-avx512 for all x86 targets,
but a runtime test needs to check avx512f effective target if the
instructions can be assembled.
The runtime test also needs to check if the target machine supports
instruction set we have been compiled for. The testsuite
Introduce vec_shl_ and vec_shr_ expanders to improve
'*a = __builtin_shufflevector(*a, (vect64){0}, 1, 2, 3, 4);'
and
'*a = __builtin_shufflevector((vect64){0}, *a, 3, 4, 5, 6);'
shuffles. The generated code improves from:
movzwl 6(%rdi), %eax
movzwl 4(%rdi), %edx
salq
On Mon, Feb 5, 2024 at 5:43 PM H.J. Lu wrote:
>
> Changes in v6:
>
> 1. Use ix86_save_reg and accessible_reg_set in
> x86_64_select_profile_regnum.
> 2. Construct a complete reg name in x86_function_profiler.
>
> Changes in v5:
>
> 1. Add pr113689-3.c.
> 2. Use %r10 if
On Fri, Feb 2, 2024 at 11:47 PM H.J. Lu wrote:
>
> Changes in v5:
>
> 1. Add pr113689-3.c.
> 2. Use %r10 if ix86_profile_before_prologue () return true.
> 3. Try a callee-saved register which has been saved on stack in the
> prologue.
>
> Changes in v4:
>
> 1. Remove pr113689-3.c.
> 2. Use
On Mon, Feb 5, 2024 at 9:06 AM Uros Bizjak wrote:
>
> On Mon, Feb 5, 2024 at 1:24 AM Roger Sayle wrote:
> >
> >
> > This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
> > that exhibits with a specific combination of command line options. The
On Wed, Jan 31, 2024 at 9:23 AM Jakub Jelinek wrote:
>
> Hi!
>
> The move of the vzeroupper pass from after reload pass to after
> postreload_cse helped only partially, CSE-like passes can still invalidate
> those notes (especially REG_UNUSED) if they use some earlier register
> holding some
On Mon, Feb 5, 2024 at 1:24 AM Roger Sayle wrote:
>
>
> This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
> that exhibits with a specific combination of command line options. The
> cause is that x86's scalar-to-vector pass converts a chain of instructions
> from TImode to
On Fri, Feb 2, 2024 at 9:59 AM Rainer Orth
wrote:
>
> gcc.target/i386/pr71321.c FAILs on 64-bit Solaris/x86 with the native
> assembler:
>
> FAIL: gcc.target/i386/pr71321.c scan-assembler-not lea.*0
>
> The problem is that /bin/as doesn't fully support cfi directives, so the
> .eh_frame section
The fix for PR70321 introduced a splitter that split a doubleword
comparison into a pair of XORs followed by an IOR to set the (zero)
flags register. To help the reload, splitter forced SUBREG pieces of
double-word input values to a pseudo, but this regressed
gcc.target/i386/pr82580.c
int f0 (U
On Thu, Feb 1, 2024 at 3:18 PM Richard Biener wrote:
>
> The following avoids re-using a register holding a pointer (and
> thus might be REG_POINTER) for the result of a pointer difference
> computation. That might confuse heuristics in (broken) RTL alias
> analysis which relies on REG_POINTER
On Wed, Jan 31, 2024 at 1:57 PM Rainer Orth
wrote:
>
> The gcc.target/i386/no-callee-saved-[12].c tests FAIL on Solaris/x86:
>
> FAIL: gcc.target/i386/no-callee-saved-1.c scan-assembler-not push
> FAIL: gcc.target/i386/no-callee-saved-2.c scan-assembler-not push
>
> In both cases, the test
On Wed, Jan 31, 2024 at 2:02 PM Rainer Orth
wrote:
>
> The gcc.target/i386/pr38534-1.c etc. tests FAIL on 32 and 64-bit
> Solaris/x86:
>
> FAIL: gcc.target/i386/pr38534-1.c scan-assembler-not push
> FAIL: gcc.target/i386/pr38534-2.c scan-assembler-not push
> FAIL: gcc.target/i386/pr38534-3.c
On Wed, Jan 31, 2024 at 3:04 PM Rainer Orth
wrote:
>
> Three patches have remained unreviewed for a week or more:
>
> c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html
>
> This one may even be
On Wed, Jan 24, 2024 at 10:07 AM Rainer Orth
wrote:
>
> gcc.target/i386/pr80833-1.c FAILs on 32-bit Solaris/x86 since 20220609:
>
> FAIL: gcc.target/i386/pr80833-1.c scan-assembler pextrd
>
> Unlike e.g. Linux/i686, 32-bit Solaris/x86 defaults to -mstackrealign,
> so this patch overrides that to
On Fri, Jan 19, 2024 at 5:50 PM Jeff Law wrote:
>
>
>
> On 1/19/24 09:05, Georg-Johann Lay wrote:
> >
> >
> > Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >>
> >> This patch tweaks RTL expansion of multi-word shifts and rotates to use
> >> PLUS rather than IOR for disjunctive operations. During
On Thu, Jan 18, 2024 at 8:31 AM Jakub Jelinek wrote:
>
> Hi!
>
> x86_function_profiler emits assembly directly into file and only emits
> AT syntax. The following patch adjusts it to emit MASM syntax
> if -masm=intel.
> As it doesn't use asm_fprintf, I can't use {|} syntax for the dialects.
>
>
On Thu, Jan 11, 2024 at 7:24 PM Fangrui Song wrote:
>
> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> mangled name). Similar constraints are available in other targets (e.g.
> "S" for aarch64/riscv, "Cs" for m68k).
>
> There isn't a good way for x86 yet, e.g. "i"
On Thu, Jan 11, 2024 at 9:33 AM Fangrui Song wrote:
>
> On 2024-01-11, Uros Bizjak wrote:
> >On Thu, Jan 11, 2024 at 4:44 AM Fangrui Song wrote:
> >>
> >> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> >> mangled name). Sim
On Thu, Jan 11, 2024 at 4:44 AM Fangrui Song wrote:
>
> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> mangled name). Similar constraints are available in other targets (e.g.
> "S" for aarch64/riscv, "Cs" for m68k).
>
> There isn't a good way for x86 yet, e.g. "i"
On Tue, Jan 9, 2024 at 11:19 AM Uros Bizjak wrote:
>
> On Tue, Jan 9, 2024 at 11:06 AM Richard Biener wrote:
> >
> > On Tue, 9 Jan 2024, Uros Bizjak wrote:
> >
> > > On Tue, Jan 9, 2024 at 10:44?AM Richard Biener wrote:
> > > >
On Tue, Jan 9, 2024 at 11:06 AM Richard Biener wrote:
>
> On Tue, 9 Jan 2024, Uros Bizjak wrote:
>
> > On Tue, Jan 9, 2024 at 10:44?AM Richard Biener wrote:
> > >
> > > On Tue, 9 Jan 2024, Uros Bizjak wrote:
> > >
> > > >
On Tue, Jan 9, 2024 at 10:44 AM Richard Biener wrote:
>
> On Tue, 9 Jan 2024, Uros Bizjak wrote:
>
> > On Tue, Jan 9, 2024 at 9:58?AM Richard Biener wrote:
> > >
> > > On Mon, 8 Jan 2024, Uros Bizjak wrote:
> > >
> > > &g
On Tue, Jan 9, 2024 at 9:58 AM Richard Biener wrote:
>
> On Mon, 8 Jan 2024, Uros Bizjak wrote:
>
> > On Mon, Jan 8, 2024 at 5:57?PM Andrew Pinski wrote:
> > >
> > > On Mon, Jan 8, 2024 at 6:44?AM Uros Bizjak wrote:
> > > >
> > > > Instea
On Mon, Jan 8, 2024 at 5:57 PM Andrew Pinski wrote:
>
> On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
> >
> > Instead of converting XOR or PLUS of two values, ANDed with two constants
> > that
> > have no bits in common, to IOR expression, convert IOR or XO
Instead of converting XOR or PLUS of two values, ANDed with two constants that
have no bits in common, to IOR expression, convert IOR or XOR of said two
ANDed values to PLUS expression.
If we consider the following testcase:
--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
On Mon, Jan 8, 2024 at 10:56 AM Richard Biener wrote:
>
> It was noticed that -mmovbe doesn't use movbe for __builtin_bswap{32,64}
> when not optimizing. The follownig adjusts the documentation to
> say it will be used for optimizing and applies to all byte swaps,
> not just those carried out
On Sat, Jan 6, 2024 at 2:30 PM Roger Sayle wrote:
>
>
> This patch improves the cost/gain calculation used during the i386 backend's
> SImode/DImode scalar-to-vector (STV) conversion pass. The current code
> handles loads and stores, but doesn't consider that converting other
> scalar operations
Hello!
I have sent an explanation on ICE in try_combine on pr112494.c [1],and
an argument that explains why we can safely ignore non-COMPARISON_P
mode changes [2].
Can we proceed with the proposed solution?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638726.html
[2]
On Sun, Dec 31, 2023 at 4:56 PM Roger Sayle wrote:
>
>
> Hi Uros,
>
> > From: Uros Bizjak
> > Sent: 28 December 2023 10:33
> > On Fri, Dec 22, 2023 at 11:14 AM Roger Sayle
> > wrote:
> > >
> > > This patch resolves the failure of pr43644-2
The post-reload splitter currently allows xmm16+ registers with TARGET_EVEX512.
The splitter changes SFmode of the output operand to V4SFmode, but the vector
mode is currently unsupported in xmm16+ without TARGET_AVX512VL. lowpart_subreg
returns NULL_RTX in this case and the compilation fails with
Move ix86_expand_unary_operator from i386.cc to i386-expand.cc, re-arrange
prototypes and do some cosmetic changes with the usage of TARGET_APX_NDD.
No functional changes.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_unary_operator_ok): Move from here...
* config/i386/i386-expand.cc
On Fri, Dec 22, 2023 at 11:14 AM Roger Sayle wrote:
>
>
> This patch resolves the failure of pr43644-2.c in the testsuite, a code
> quality test I added back in July, that started failing as the code GCC
> generates for 128-bit values (and their parameter passing) has been in
> flux. After a few
The move to the output operand should use high register input operand.
PR target/113044
gcc/ChangeLog:
* config/i386/i386.md (*ashlqi_ext_1): Move from the
high register of the input operand.
(*qi_ext_1): Ditto.
gcc/testsuite/ChangeLog:
On Wed, Dec 13, 2023 at 10:21 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch makes most of x86 MD builtins nothrow,leaf
> (like most middle-end builtins are). For -fnon-call-exceptions it
> doesn't nothrow, better might be to still add it if the builtins
> don't read or write memory and
On Tue, Dec 19, 2023 at 10:00 AM Jakub Jelinek wrote:
>
> Hi!
>
> Apparently when looking for "signbit2" vector expanders, I've only
> looked at sse.md and forgot mmx.md, which has two further ones and the
> following patch still ICEd.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and
On Mon, Dec 18, 2023 at 6:18 PM Roger Sayle wrote:
>
>
> This patch fixes two issues with the handling of 128-bit TImode integer
> constants in the x86_64 backend. The main issue is that GCC always
> tries to load 128-bit integer constants via broadcasts to vector SSE
> registers, even if the
Eliminate redundant compare between set{z,nz} and j{z,nz}:
setz %al; test %al,%al; jz <...> -> setz %al; jnz <...> and
setnz %al, test %al,%al; jz <...> -> setnz %al; jz <...>.
We can use the original Zero-flag value instead of setting the
temporary register and testing it for zero.
On Wed, Dec 6, 2023 at 9:08 AM Hongyu Wang wrote:
>
> Hi,
>
> Following up the discussion of V2 patches in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639368.html,
> this patch series add early clobber for all TImode NDD alternatives
> to avoid any potential overlapping between dest
On Wed, Dec 6, 2023 at 2:31 AM Hongyu Wang wrote:
>
> Uros Bizjak 于2023年12月5日周二 18:46写道：
>
> >
> > On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote:
> > >
> > > Under APX NDD, previous TImode allocation will have issue that it was
> > > original
On Tue, Dec 5, 2023 at 8:28 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2
> I've added a while back to use smaller code than movabsq if possible.
> If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates
> an invalid
On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote:
>
> From: Kong Lingling
>
> Legacy adc patterns are commonly adopted to TImode add, when extending TImode
> add to NDD version, operands[0] and operands[1] can be different, so extra
> move
> should be emitted if those patterns have optimization
On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote:
>
> From: Kong Lingling
>
> gcc/ChangeLog:
>
> * config/i386/i386.md: (addsi_1_zext): Add new alternatives for
> NDD and adjust output templates.
> (*add_2): Likewise.
> (*addsi_2_zext): Likewise.
>
On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang wrote:
>
> Under APX NDD, previous TImode allocation will have issue that it was
> originally allocated using continuous pair, like rax:rdi, rdi:rdx.
>
> This will cause issue for all TImode NDD patterns. For NDD we will not
> assume the arithmetic
1 - 100 of 6043 matches
Mail list logo
