On Wed, Dec 13, 2023 at 4:44 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes ICE on the testcase in similar way to how
> other folded builtins are handled in ix86_gimple_fold_builtin when
> they don't have a lhs; these builtins are const or pure, so normally
> DCE would remove them l
Hi!
The following patch fixes ICE on the testcase in similar way to how
other folded builtins are handled in ix86_gimple_fold_builtin when
they don't have a lhs; these builtins are const or pure, so normally
DCE would remove them later, but with -O0 that isn't guaranteed to
happen, and during expa
On Fri, Nov 24, 2023 at 9:31 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because cbranchv16qi4 expansion calls
> ix86_expand_branch with op1 being a pre-AVX unaligned memory and
> ix86_expand_branch emits a xorv16qi3 instruction without making sure
> the operand predicates are
Hi!
The following testcase ICEs, because cbranchv16qi4 expansion calls
ix86_expand_branch with op1 being a pre-AVX unaligned memory and
ix86_expand_branch emits a xorv16qi3 instruction without making sure
the operand predicates are satisfied.
While I could manually check if the argument (or both?)
On Mon, Nov 20, 2023 at 5:33 PM Uros Bizjak wrote:
>
> With the above two options, use a temporary register regno (as returned
> from split_stack_prologue_scratch_regno) as an indirect call scratch
> register to hold __morestack function address. On 64-bit targets, two
> temporary registers are a
With the above two options, use a temporary register regno (as returned
from split_stack_prologue_scratch_regno) as an indirect call scratch
register to hold __morestack function address. On 64-bit targets, two
temporary registers are always available, so load the function address in
%r11 and call
On Fri, May 13, 2022 at 1:43 PM liuhongt wrote:
>
> When d->perm[i] == d->perm[i-1] + 1 and d->perm[i] == nelt, it's not
> continuous. It should fail if there's more than 2 continuous areas.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
>
> gcc/ChangeLog:
>
>
When d->perm[i] == d->perm[i-1] + 1 and d->perm[i] == nelt, it's not
continuous. It should fail if there's more than 2 continuous areas.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/105587
* config/i386/i386-expand.cc
(
On Mon, Apr 11, 2022 at 6:50 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because ix86_emit_i387_log1p attempts to
> emit something like
> if (cond)
> some_code1;
> else
> some_code2;
> and emits a conditional jump using emit_jump_insn (standard way in
> the file) a
Hi!
The following testcase ICEs, because ix86_emit_i387_log1p attempts to
emit something like
if (cond)
some_code1;
else
some_code2;
and emits a conditional jump using emit_jump_insn (standard way in
the file) and an unconditional jump using emit_jump.
The problem with that is that if
uot; } */
> +/* { dg-final { scan-assembler-not "kandn" } } */
> +/* { dg-final { scan-assembler-times "andn" 1 } } */
> +
> +int b, c, d;
> +int r;
> +
> +void
> +__attribute__((target("bmi")))
> +foo ()
> +{
> + r = ((b & ~d) | (c
For define_insn_and_split "*xor2andn":
1. Refine predicate of operands[0] from nonimmediate_operand to
register_operand.
2. Remove TARGET_AVX512BW from condition to avoid kmov when TARGET_BMI
is not available.
3. Force_reg operands[2].
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok
On Tue, Nov 30, 2021 at 10:43 AM liuhongt wrote:
>
> ix86_attr_length_immediate_default assume TYPE ishift only have 1
> constant operand,
> but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
> condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
> INTVAL (operands[3]
On Tue, Nov 30, 2021 at 5:44 PM liuhongt via Gcc-patches
wrote:
>
> ix86_attr_length_immediate_default assume TYPE ishift only have 1
> constant operand,
> but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
> condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
> INTV
ix86_attr_length_immediate_default assume TYPE ishift only have 1
constant operand,
but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
INTVAL (operands[3]) == 64 - INTVAL (operands[2]), and hit
gcc_assert.
Explicitly
2021-10-18 Uroš Bizjak
PR target/102761
gcc/ChangeLog:
* config/i386/i386.c (ix86_print_operand_address):
Error out for non-address_operand asm operands.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr102761.c: New test.
Boostrapped and regression tested on x86_64-linux-gnu {
On Sat, Sep 18, 2021 at 03:56:42PM +0800, Hongtao Liu wrote:
> > Wouldn't it be better to do:
> > E_VOIDmode:
> > gcc_assert (convert_p);
> !convert_p, Must be typo :)
Yes, sorry.
>
> > break;
> > default:
> > gcc_unreachable ();
> > ?
> Sur
On Sat, Sep 18, 2021 at 3:31 PM Jakub Jelinek wrote:
>
> On Sat, Sep 18, 2021 at 11:09:32AM +0800, liuhongt wrote:
> > Besides conversion instructions, pass_rpad also handles scalar
> > sqrt/rsqrt/rcp/round instructions, while r12-3614 should only want to
> > handle conversion instructions, so fix
On Sat, Sep 18, 2021 at 11:09:32AM +0800, liuhongt wrote:
> Besides conversion instructions, pass_rpad also handles scalar
> sqrt/rsqrt/rcp/round instructions, while r12-3614 should only want to
> handle conversion instructions, so fix it.
>
> Bootstrapped and regtest on x86_64-linux-gnu{-m32,}
Besides conversion instructions, pass_rpad also handles scalar
sqrt/rsqrt/rcp/round instructions, while r12-3614 should only want to
handle conversion instructions, so fix it.
Bootstrapped and regtest on x86_64-linux-gnu{-m32,} w/ configure
--enable-checking=yes,rtl,extra, failed tests are fixed
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Pushed to trunk.
gcc/ChangeLog:
PR target/102016
* config/i386/sse.md (*avx512f_pshufb_truncv8hiv8qi_1): Add
TARGET_AVX512BW to condition.
gcc/testsuite/ChangeLog:
PR target/102016
* gcc.target/i3
On Mon, Aug 16, 2021 at 11:19 AM liuhongt wrote:
>
> Hi:
> avx512f_scalef2 only accept register_operand for operands[1],
> force it to reg in ldexp3.
>
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk.
>
> gcc/ChangeLog:
>
> PR target/101930
> * config/
Hi:
avx512f_scalef2 only accept register_operand for operands[1],
force it to reg in ldexp3.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk.
gcc/ChangeLog:
PR target/101930
* config/i386/i386.md (ldexp3): Force operands[1] to
reg.
gcc/testsuite
On Fri, Jun 04, 2021 at 01:03:58AM +, Liu, Hongtao wrote:
> Thanks for the review.
> Yes, you're right, AVX512VL parts are already guaranteed by
> ix86_hard_regno_mode_ok.
>
> Here is updated patch.
One remaining thing, could you try to modify the testcase back to
#include and using intrins
>-Original Message-
>From: Jakub Jelinek
>Sent: Thursday, June 3, 2021 9:49 PM
>To: Liu, Hongtao
>Cc: gcc-patches@gcc.gnu.org
>Subject: Re: [PATCH] [i386] Fix ICE of insn does not satisfy its constraints.
>
>On Thu, Jun 03, 2021 at 05:07:26PM +0800, liuhon
On Thu, Jun 03, 2021 at 05:07:26PM +0800, liuhongt via Gcc-patches wrote:
> @@ -18163,10 +18163,10 @@ (define_expand "v16qiv16si2"
>"TARGET_AVX512F")
>
> (define_insn "avx2_v8qiv8si2"
> - [(set (match_operand:V8SI 0 "register_operand" "=v")
> + [(set (match_operand:V8SI 0 "register_operand
For evex encoding extended instructions, when vector length is less
than 512 bits, AVX512VL is needed, besides some instructions like
vpmovzxbx need extra AVX512BW. So this patch refines corresponding
constraints, i.e. from "v/vm" to "Yv/Yvm", from "v/vm" to "Yw/Ywm".
Bootstrapped and regtested on
On Tue, Sep 6, 2016 at 5:06 PM, Jakub Jelinek wrote:
> On Mon, Sep 05, 2016 at 08:58:12PM +0200, Uros Bizjak wrote:
>> ... perhaps we can emit a warning here and expand the builtin as a
>> call? This way, we will mirror the case when builtin requires some
>> ISA, e.g.:
>>
>> void foo ()
>> {
>>
On Mon, Sep 05, 2016 at 08:58:12PM +0200, Uros Bizjak wrote:
> ... perhaps we can emit a warning here and expand the builtin as a
> call? This way, we will mirror the case when builtin requires some
> ISA, e.g.:
>
> void foo ()
> {
> __builtin_ia32_stmxcsr();
> }
>
> $ gcc -S -mno-sse dd.c
> dd
On Mon, Sep 5, 2016 at 7:14 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, if we want to diagnose a md builtin not enabled in
> the current ISA, we call error and then return const0_rtx. That isn't a
> good choice if the result is BLKmode, which can happen for vector modes
> that aren'
Hi!
As the testcase shows, if we want to diagnose a md builtin not enabled in
the current ISA, we call error and then return const0_rtx. That isn't a
good choice if the result is BLKmode, which can happen for vector modes
that aren't enabled in the current ISA. In that case, returning target
is
Hello!
Renaming UNSPEC_MOVNT to UNSPEC_MOVNTI was not a good idea, since it caused [1]:
prefetch-8.c: In function ‘test’:
prefetch-8.c:16:1: error: unrecognizable insn:
(insn 15 14 16 4 (set (mem:SI (plus:SI (mult:SI (reg/v:SI 64 [ i ])
(const_int 4 [0x4]))
(re
32 matches
Mail list logo
