like r16-105-g599bca27dc37b3, the patch handles redunduant clean up of
upper-bits for maskload.
.i.e
Successfully matched this instruction:
(set (reg:V4DF 175)
(vec_merge:V4DF (unspec:V4DF [
(mem:V4DF (plus:DI (reg/v/f:DI 155 [ b ])
(reg:DI 143 [ ivtmp.56
> > It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
>
> Please mention that in the changelog. Also ...
Changed.
> Please put this condition in the set of conds we test in the else branch of
> ...
>
> > > /* Do not place the same access in the interleaving chain
> > > twice.
From: "hongtao.liu"
AutoFDO profile is a scaled profile, as a result, 0 sample does not
mean never executed. especially there's profile from function
body. Prevent combine_with_ipa_count·(ipa_count) from zeroing all
bb->count.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
OK for trunk
Changed, here's the updated patch I'm going to check in.
REAL_CST is handled if it can be represented in different floating
point types without loss of precision or under fast math.
gcc/ChangeLog:
PR tree-optimization/103771
* match.pd (cond_expr_convert_p): Extend the match to h
The patch tries to solve miss vectorization for below case.
void
foo (int* a, int* restrict b)
{
b[0] = a[0] * a[64];
b[1] = a[65] * a[1];
b[2] = a[2] * a[66];
b[3] = a[67] * a[3];
b[4] = a[68] * a[4];
b[5] = a[69] * a[5];
b[6] = a[6] * a[70];
b[7] = a[7] * a[71];
}
1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b)
2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b)
Prof is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994#c6
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR middle
So it won't do the unsafe truncation for double(1.001) to float(1.0)
since there's precision loss.
It's guarded by testcase pr103771-6.c
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
REAL_CST is handled if it can be represented in different floating
point typ
Update in V3
> > > + cost_sse_integer = 0;
> > > + weighted_cost_sse_integer = 0 ;
> Extra space here.
Changed.
> > > + : ix86_size_cost.sse_to_integer;
>
> Please be sure to not revert the changes from my patch adding
> COSTS_N_INSNS (...) / 2
> here and some other places.
Yes, keep the
The Intel Decimal Floating-Point Math Library is available as open-source on
Netlib[1].
[1] https://www.netlib.org/misc/intel/
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
libgcc/config/libbid/ChangeLog:
* bid128_string.c (MIN_DIGITS): New macro.
Updated in V2
>
> Can you instead of mangling in float support use separate (match like
> for the below cases?
I tried, but reported duplicated defination since they share same pattern
like
(cond (simple_comparison@6 @0 @1) (convert@4 @2) (convert@5 @3))
No idea how to split that.
>
> > @@ -1130
REAL_CST is handled if it can be represented in different floating
point types without loss of precision or under fast math.
gcc/ChangeLog:
PR tree-optimization/103771
* match.pd (cond_expr_convert_p): Extend the match to handle
REAL_CST.
* tree-vect-patterns.cc
The only part I changed is related to size_cost of sse_to_ineteger, as below
114+ /* Under TARGET_SSE4_1, it's vmovd + vpextrd/vpinsrd.
115+ W/o it, it's movd + psrlq/unpckldq + movd. */
116+ else if (!TARGET_64BIT && smode != SImode)
117+cost *= TARGET_SSE4_1 ? 2 : 3;
118+
Ok for trun
From: "hongtao.liu"
> The check you added seems correct to me. Do we need to keep the
> afdo_string_table->get_index (IDENTIFIER_POINTER (
> DECL_ASSEMBLER_NAME (edge->callee->decl))) != s->name ()
> check? Should your check replace it rather than be an additional check?
I verified t
From: "hongtao.liu"
> another thing, you can save the walk over PHI args by using
>
> gimple_phi_arg_location (phi, tmp_e->dest_idx);
>
Changed, use gimple_phi_arg_location_from_edge (phi, tmp_e);
For an empty BB with all debug_stmt, it will be ignored by
afdo_set_bb
> I am generally trying to get rid of remaing uses of REG_FREQ since the
> 1 based fixed point arithmetics iot always working that well.
>
> You can do the sums in profile_count type (doing something reasonable
> when count is uninitialized) and then convert it to sreal for the final
> heuristi
Since the tune if only for GLC(sapphirerapids and alderlake-P).
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk and backport to GCC15/GCC14/GCC13 release branches.
gcc/ChangeLog:
* config/i386/x86-tune.def (X86_TUNE_DEST_FALSE_DEP_FOR_GLC):
Remove ot
For floating point, !flag_trapping_math is needed for the pattern which
transforms 2 conversions to 1 conversion, and may lose 1 potential trap.
There shouldn't be any accuracy issue.
It also handles real_cst if it can be represented in different floating point
types without loss of precision.
Bo
From: "hongtao.liu"
> I think the comment is a bit off, it should be "For an empty BB ..." since
> we should not change behavior on whether there are debug stmts or not.
Changed.
For an empty BB with all debug_stmt, it will be ignored by
afdo_set_bb_count, but it can be set with count of single
From: "hongtao.liu"
For BB with all debug_stmt, it will be ignored by afdo_set_bb_count,
but it can be set with count of single successors PHIs which edge from
the BB.(only nonzero count is annotatted).
Tested with -march=x86-64-v3 -O2 autofdo enabled, the issue in the PR
is fixed.
Bootstrapped
From: "hongtao.liu"
Function name in afdo_string_table is step3d_t_tile.
but DECL_ASSEMBLER_NAME (edge->callee->decl))) gets
__step3d_t_mod_MOD_step3d_t_tile, Looks like the prefix is not in the
debug string table, so let's also check directly for
afdo_string_table->get_index_by_decl (edge->calle
This is originally from [1]
For the command line, or target attribute, the actual operation goes
into ix86_handle_option, and as long as we get it right in this
ix86_handle_option, everything else should be fine.
As for the macros generated by the mask name (TARGET_SSE4_1_P), their
mea
cat test.c
void
foo ()
{
__mmask8 mask1 = _mm_cmpeq_epu32_mask (pi128[0], pi128[1]);
a = mask1 & 15;
}
with -O2 -march=x86-64-v4, gcc generates
foo():
movqpi128(%rip), %rax
vmovdqa (%rax), %xmm0
vpcmpeqd16(%rax), %xmm0, %k0
kmovb %k0, %eax
Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
or vpandn.
Current register_operand/vector_operand could lose some optimization
opportunity.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/predicates.md (vector
From: "hongtao.liu"
When FMA is available, N-R step can be rewritten with
a / b = (a - (rcp(b) * a * b)) * rcp(b) + rcp(b) * a
which have 2 fma generated.[1]
[1] https://bugs.llvm.org/show_bug.cgi?id=21385
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog
In some benchmark, I notice stv failed due to cost unprofitable, but the igain
is inside the loop, but sse<->integer conversion is outside the loop, current
cost
model doesn't consider the frequency of those gain/cost.
The patch weights those cost with frequency just like LRA does.
Bootstrapped a
Look like those operand modifiers are only for internal usage
in .md files, so for simplicity, I'll just remove them from extend.texi.
Ready push to trunk.
gcc/ChangeLog:
PR documentation/108134
* doc/extend.texi: Remove documents from r11-344-g0fec3f62b9bfc0.
---
gcc/doc/extend
*jcc only supports ix86_fp_comparison_operator for CCFP, when
comparison code is LT, there's an ICE. W/o AVX10.2, it's ok since
do_compare_rtx_and_jump will transform LT to GT, but w/ AVX10.2 it
goes directly into ix86_expand_branch which doesn't handle it.
Use ix86_fp_comparison_operator in cbran
It looks like the testcase is fragile, it's supposed to check the
compiler ability of generating code_6_gottpoff_reloc instruction, but
failed since there's a seg_prefixed memory
usage(r14-6242-gd564198f960a2f).
mov r13, QWORD PTR j@gottpoff[rip]
mov r12, QWORD PTR a@gottpo
After optimization for RA, memory op is not propagated into
instructions(>1), and it make testcases not generate vxorps since
the memory is loaded into the dest, and the dest is never unused now.
So rewrite testcases to make the codegen more stable.
gcc/testsuite/ChangeLog:
* gcc.target/
gcc/ChangeLog:
PR rtl-optimization/108707
* ira-costs.cc (scan_one_insn): Use NO_REGS instead of
GENERAL_REGS when preferred reg_class is not known.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr108707.c: New test.
(cherry picked from commit 0368d169492017cfab5622
r14-172-g0368d169492017 replaces GENERAL_REGS with NO_REGS in cost
calculation when the preferred register class are not known yet.
It regressed powerpc PR109610 and PR109858, it looks too aggressive to use
NO_REGS when mode can be allocated with GENERAL_REGS.
The patch takes a step back, still use
2 and r14-1252 to
GCC13 and GCC12 release branch.
Note r14-1252 is a fix to r14-172 which regressed powerpc testcase in PR109610.
I have verified the fix also works on GCC13/GCC12 branch for PR109610.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}, and aarch64-linux-gnu.
Ok for backport
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/118489
* config/i386/sse.md (VF1_AVX512BW): Fix typo.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr118489.c: New test.
---
gcc/config/i386/sse.md |
Since there's regression to use vpermq, and it's manually disabled by
!TARGET_AVX512BW. I remove the codes related to vpermq and make
ix86_expand_vecop_qihi2 only handle vpmovbw + op + vpmovwb case.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/ChangeLog:
> Please pass 'sbitmap' instead of auto_sbitmap&, it should properly
> decay to that. Applies everywhere I think.
>
Changed.
> In fact I wonder whether we should simply populate the bitmap
> from a
>
> for (auto loop : loops_list (cfun, LI_ONLY_INNERMOST))
> bitmap_set_bit (original_innerm
r15-919-gef27b91b62c3aa removed 1 / 3 size reduction for innermost
loop, but it doesn't accurately remember what's "innermost" for 2
testcases in PR117888.
1) For pass_cunroll, the "innermost" loop could be an originally outer
loop with inner loop completely unrolled by cunrolli. The patch moves
l
When loop requires any kind of versioning which could increase register
pressure too much, and it's in a deeply nest big loop, don't do
vectorization.
I tested the patch with both Ofast and O2 for SPEC2017, besides 548.exchange_r,
other benchmarks are same binary.
Bootstrapped and regtested 0on x
It could cause weired spill in RA when register pressure is high.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
BTW, It's difficult to get a decent testcase for the issue since the spill
is not exposed in simple testcase.
gcc/ChangeLog:
PR target/117562
hw instruction doesn't raise exceptions, turns sNAN into qNAN quietly,
and always round to nearest (even). Output denormals are always
flushed to zero and input denormals are always treated as zero. MXCSR
is not consulted nor updated.
W/o native instructions, flag_unsafe_math_optimizations is neede
Disable the tune for Zhaoxin/CLX/SKX since it could hurt performance
for the inner loop.
According to last test, align_loop helps performance for SPEC2017 on EMR and
Znver4.
So I'll still keep the tune for generic part.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Any comment?
gcc/
Force_operand issues an ICE when input
is (subreg:DI (us_truncate:V8QI)), it's probably because it's an
invalid rtx, So refine backend patterns for that.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/117318
* config/i386/s
It's supported by vector permutation with zero vector.
gcc/ChangeLog:
* config/i386/i386-expand.cc
(ix86_expand_vector_bf2sf_with_vec_perm): New function.
* config/i386/i386-protos.h
(ix86_expand_vector_bf2sf_with_vec_perm): New Declare.
* config/i386/mmx.m
Generate native instruction whenever possible, otherwise use vector
permutation with odd indices.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/i386-expand.cc
(ix86_expand_vector_sf2bf_with_vec_perm): New function.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk and backport to release branch.
gcc/ChangeLog:
PR target/117240
* config/i386/i386-builtin.def: Add avx/avx512f to vaes
ymm/zmm builtins.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr11
r15-974-gbf7745f887c765e06f2e75508f263debb60aeb2e has optimized for
jcc/setcc, but missed movcc.
The patch supports movcc.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/117232
* config/i386/sse.md (*kortest_cmp_movqicc):
The optimization relies on other patterns which are only available at
GCC14 and obove, so restore the xfail for GCC13/12 branch.
Pushed as an obvious fix.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512bw-pr103750-2.c: Add xfail for ia32.
---
gcc/testsuite/gcc.target/i386/avx512bw-pr1
r12-6103-g1a7ce8570997eb combines vpcmpuw + zero_extend to vpcmpuw
with the pre_reload splitter, but the splitter transforms the
zero_extend into a subreg which make reload think the upper part is
garbage, it's not correct.
The patch adjusts the zero_extend define_insn_and_split to
define_insn to
Also add hard_float target to avoid failed on arm-eabi, cortex-m0.
Verified on cross-compiler for powerpc64le-linux-gnu, sparc-sun-solaris2.11
Ready push to trunk.
gcc/testsuite/ChangeLog:
PR testsuite/115365
* gcc.dg/pr100927.c: Adjust testcase to avoid scan FIX in REG_EQUIV.
-
---
htdocs/gcc-15/changes.html | 10 ++
1 file changed, 10 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 6dc46a52..8a238256 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -36,6 +36,16 @@ a work-in-progress.
General
For masked FMA, there're 2 forms of RTL representation
1) (vec_merge (fma: op2 op1 op3) op1) mask)
2) (vec_merge (fma: op1 op2 op3) op1) mask)
It's because op1 op2 are communatative in RTL(the second op1 is
written as (match_dup 1))
we once tried to replace (match_dup 1)
with (match_operand:VFH_AV
For x86 masked fma, there're 2 rtl representations
1) (vec_merge (fma op2 op1 op3) op1 mask)
2) (vec_merge (fma op1 op2 op3) op1 mask).
5894(define_insn "_fmadd__mask"
5895 [(set (match_operand:VFH_AVX512VL 0 "register_operand" "=v,v")
5896(vec_merge:VFH_AVX512VL
5897 (fma:VF
diate_operand" "0")) to enable more flexibility for pattern
match and recog, but it triggered an ICE in reload(reload can handle
at most one perand with "0" constraint).
So we need either add 2 patterns in the backend or just do the
canonicalization in the middle-end.
The
Update in V3.
>The testcase looks bogus:
>
> b[i+k] = b[i+k-5] + 2;
>
>accesses b[-3], can you instead adjust the inner loop to start with k == 4?
Changed, also adjust b[100] to b[200] to avoid array out of bound.
>Please remove this testcase - even with fully masking we'd need alias
>versi
>We'd also need to update the documentation:
>... The @samp{very-cheap} model only
>allows vectorization if the vector code would entirely replace the
>scalar code that is being vectorized. For example, if each iteration
>of a vectorized loop would only be able to handle exactly four iterations
>
r15-1737-gb06a108f0fbffe lower AVX512 kmask comparison to AVX2 ones,
but wrong lowered unsigned comparison to signed ones, for unsigned
comparison, only EQ/NEQ can be lowered.
The commit fix that.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
For Crestmont, 4-operand vex blendv instructions come from MSROM and
is slower than 3-instructions sequence (op1 & mask) | (op2 & ~mask).
legacy blendv instruction can still be handled by the decoder.
The patch add a new tune which is enabled for all processors except
for SRF/CWF. It will use vpan
According to Intel SOM[1], For Crestmont, most 256-bit Intel AVX2
instructions can be decomposed into two independent 128-bit
micro-operations, except for a subset of Intel AVX2 instructions,
known as cross-lane operations, can only compute the result for an
element by utilizing one or more source
ped and regtested on x86_64-pc-linux-gnu{-m32,}.
The patch generally improves SPEC2017 allrate geomean by 1% with
-march=sierraforest -Ofast on SRF.
Ready push to trunk.
liuhongt (2):
[x86] Add new microarchitecture tune for SRF/GRR/CWF.
[x86] Add a new tune avx256_avoid_vec_perm for SRF.
gcc/testsuite/ChangeLog:
* gcc.dg/fstack-protector-strong.c: Adjust
scan-assembler-times.
* gcc.dg/graphite/scop-6.c: Add
-Wno-aggressive-loop-optimizations.
* gcc.dg/graphite/scop-9.c: Ditto.
* gcc.dg/tree-ssa/ivopts-lt-2.c: Add -fno-tree-vectorize.
>So should we adjust very-cheap to allow niter peeling as proposed or
>should we switch the default at -O2 to cheap?
I prefer the former.
Update in V2:
Adjust testcase after relax O2 vectorization.
Ok for trunk?
gcc/ChangeLog:
* tree-vect-loop.cc (vect_analyze_loop_costing): Enable
Return constm1_rtx when GET_MODE_CLASS (MODE) == MODE_VECTOR_INT.
Otherwise NULL_RTX.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/i386.h (VECTOR_STORE_FLAG_VALUE): New macro.
gcc/testsuite/ChangeLog:
* gcc.dg/rtl/x8
GCC12 enables vectorization for O2 with very cheap cost model which is
restricted
to constant tripcount. The vectorization capacity is very limited w/
consideration
of codesize impact.
The patch extends the very cheap cost model a little bit to support variable
tripcount.
But still disable peel
According to Intel Software Optimization Manual[1], the Redwood cove
microarchitecture supports LD+OP and MOV+OP macro fusions.
The patch enables MOV+OP tune for GNR.
[1]
https://www.intel.com/content/www/us/en/content-details/814198/intel-64-and-ia-32-architectures-optimization-reference-manual
It fix the regression by
a51f2fc0d80869ab079a93cc3858f24a1fd28237 is the first bad commit
commit a51f2fc0d80869ab079a93cc3858f24a1fd28237
Author: liuhongt
Date: Wed Sep 4 15:39:17 2024 +0800
Handle const0_operand for *avx2_pcmp3_1.
caused
FAIL: gcc.target/i386/pr59539-1.c scan-assembler
*_eq3_1 supports
nonimm_or_0_operand for op1 and op2, pass_combine would fail to lower
avx512 comparision back to avx2 one when op1/op2 is const0_rtx. It's
because the splitter only support nonimmediate_operand.
Failed to match this instruction:
(set (reg/i:V16QI 20 xmm0)
(vec_merge:V16QI (con
> Can the above loop be a part of ix86_check_avx_upper_register, so this
> function would scan the full RTX for avx upper register?
Changed, also adjust ix86_check_avx_upper_stores and ix86_avx_u128_mode_needed
to either inline the old ix86_check_avx_upper_register or replace
FOR_EACH_SUBRTX
with
For function arguments/return, when it's BLK mode, it's put in a
parallel with an expr_list, and the expr_list contains the real mode
and registers.
Current ix86_check_avx_upper_register only checked for SSE_REG_P, and
failed to handle that. The patch extend the handle to each subrtx.
Bootstrapped
> You are possibly overwriting src_related_elt - I'd suggest to either break
> here or do the loop below for each found elt?
Changed.
> Do we know that will always succeed?
1) validate_subreg allows subreg for 2 vector modes with same component modes.
2) gen_lowpart in cse.cc is defined as gen_low
For mode2 bigger than 16-bytes, when it can be allocated to FIRST_SSE_REGS,
then it can only be allocated to ALL_SSE_REGS, and it can be tiebale
to all mode1 with smaller size which is available to FIRST_SSE_REGS.
When modes is equal to 16 bytes, exclude non-vector modes(TI/TFmode).
This is need fo
Also try to handle redundant broadcasts when there's already a
broadcast to a bigger mode with exactly the same component value.
For broadcast, component mode needs to be the same.
For all-zeros/ones, only need to check the bigger mode.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} and
For mode2 bigger than 16-bytes, when it can be allocated to FIRST_SSE_REGS,
then it can only be allocated to ALL_SSE_REGS, and it can be tiebale
to all mode1 with smaller size which is available to FIRST_SSE_REGS.
When modes is equal to 16 bytes, exclude non-vector modes(TI/TFmode).
This is need fo
Looks like -mprefer-vector-width=128 doesn't impact store_max/mov_max
for GCC13/GCC12 branch, explicitly use -mmov-max=128, -mstore-max=128
for those testcases.
Committed as an obvious fix.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pieces-memcpy-10.c: Use -mmove-max=256 and
-mst
When none of mprefer-vector-width, avx256_optimal/avx128_optimal,
avx256_store_by_pieces/avx512_store_by_pieces is specified, GCC will
set ix86_{move_max,store_max} as max available vector length except
for AVX part.
if (TARGET_AVX512F_P (opts->x_ix86_isa_flags)
&&
>From [1]
> > It's not obvious to me why movv16qi requires a nonimmediate_operand
> > source, especially since ix86_expand_vector_mode does have code to
> > cope with constant operand[1]s. emit_move_insn_1 doesn't check the
> > predicates anyway, so the predicate will have little effect.
> >
> > A
It results in 2 failures for x86_64-pc-linux-gnu{\
-march=cascadelake};
gcc: gcc.target/i386/extendditi3-1.c scan-assembler cqt?o
gcc: gcc.target/i386/pr113560.c scan-assembler-times \tmulq 1
For pr113560.c, now GCC generates mulx instead of mulq with
-march=cascadelake, which should be optimal,
It results in 2 failures for x86_64-pc-linux-gnu{\
-march=cascadelake};
gcc: gcc.target/i386/extendditi3-1.c scan-assembler cqt?o
gcc: gcc.target/i386/pr113560.c scan-assembler-times \tmulq 1
For pr113560.c, now GCC generates mulx instead of mulq with
-march=cascadelake, which should be optimal,
> Are there any assumptions that BB_HEAD must be a note or label?
> Maybe we should move ix86_align_loops into a separate pass and insert
> the pass just before pass_final.
The patch inserts .p2align after endbr pass, it can also fix the issue.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m3
Ok for trunk?
---
htdocs/gcc-14/changes.html| 7 +++
htdocs/gcc-14/porting_to.html | 9 +
2 files changed, 16 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index ca4cae0f..b023a4b9 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/ch
(insn 98 94 387 2 (parallel [
(set (reg:TI 337 [ _32 ])
(ashift:TI (reg:TI 329)
(reg:QI 521)))
(clobber (reg:CC 17 flags))
]) "test.c":11:13 953 {ashlti3_doubleword}
is reloaded into
(insn 98 452 387 2 (parallel [
(se
(insn 98 94 387 2 (parallel [
(set (reg:TI 337 [ _32 ])
(ashift:TI (reg:TI 329)
(reg:QI 521)))
(clobber (reg:CC 17 flags))
]) "test.c":11:13 953 {ashlti3_doubleword}
is reloaded into
(insn 98 452 387 2 (parallel [
(se
For below pattern, RA may still allocate r162 as v/k register, try to
reload for address with leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rsi
which result a linker error.
(set (reg:DI 162)
(mem/u/c:DI
(const:DI (unspec:DI
[(symbol_ref:DI ("a") [flags 0x60] )]
ix86_hardreg_mov_ok is added by r11-5066-gbe39636d9f68c4
>The solution proposed here is to have the x86 backend/recog prevent
>early RTL passes composing instructions (that set likely_spilled hard
>registers) that they (combine) can't simplify, until after reload.
>We allow sets fr
> Also, in case the insn is deleted, do:
>
> emit_note (NOTE_INSN_DELETED);
>
> DONE;
>
> instead of leaving (const_int 0) in the stream.
>
> So, the above insn preparation statements should read:
>
> --cut here--
> if (constm1_operand (operands[2], mode))
> emit_move_insn (operands[0], operands[
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/115843
* config/i386/predicates.md (const0_or_m1_operand): New
predicate.
* config/i386/sse.md (*_store_mask_1): New
pre_reload define_insn_and_split.
>- _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0);
>- # DEBUG old => (long int) _5
>+ _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0,
>__atomic_fetch_or_8);
>+ # DEBUG old => NULL
> # DEBUG BEGIN_STMT
>- # DEBUG D#2 => _5 & 1
>+ # DEBUG D#2 => NULL
>...
>- _10 = ~_5;
>-
I have a build failure on NetBSD as the namespace pollution avoidance causes
a direct hit with the system /usr/include/math.h
===
In file included from /usr/src/local/gcc/obj/gcc/include/emmintrin.h:31,
from
/usr
>> Hmm, now all avx512 tests SIGILL when testing with -m32:
>>
>> Dump of assembler code for function __get_cpuid_count:
>> => 0x08049500 <+0>: kmovd %eax,%k2
>> 0x08049504 <+4>: kmovd %edx,%k1
>> 0x08049508 <+8>: pushf
>> 0x08049509 <+9>: pushf
>> 0x0804950a <+10>:
From: "H.J. Lu"
>The above reads like it would be worth splitting branc_prediction_hits
>into branch_prediction_hints_taken and branch_prediction_hints_not_taken
>given not-taken is the default and thus will just increase code size?
>According to Intel® 64 and IA-32 Architectures Optimization Ref
The patch can avoid SIGILL on non-AVX512 machine due to kmovd is
generated in dynamic check.
Committed as an obvious fix.
gcc/testsuite/ChangeLog:
PR target/115748
* gcc.target/i386/avx512-check.h: Move runtime check into a
separate function and guard it with target ("no-
From: "H.J. Lu"
According to Intel® 64 and IA-32 Architectures Optimization Reference
Manual[1], Branch Hint is updated for Redwood Cove.
cut from [1]-
Starting with the Redwood Cove microarchitecture, if the predictor has
no stored information about a branch, the
late_combine will combine lshift + zero into *lshifrtsi3_1_zext which
cause extra mov between gpr and kmask, add ?k to the pattern.
gcc/ChangeLog:
PR target/115610
* config/i386/i386.md (<*insnsi3_zext): Add alternative ?k,
enable it only for lshiftrt and under avx512bw.
Move pass_stv2 and pass_rpad after pre_reload pass_late_combine, also
define target_insn_cost to prevent post_reload pass_late_combine to
revert the optimziation did in pass_rpad.
Adjust testcases since pass_late_combine generates better code but
break scan assembly.
.i.e
Under 32-bit target, gcc
hen do the real operation.
After enabling flate_combine, they're combined into embeded broadcast
operations.
Tested with SPEC2017, flate_combine reduces codesize by ~0.6%, which means
there're lots of small improvements.
Bootstrapped and regtested on x86_64-pc-linu-gnu{-m32,}.
Ok
The testcases are supposed to scan for vpopcnt{b,w,d,q} operations
with k mask, but mask is defined as uninitialized local variable which
will be set as 0 at rtl expand phase.
And it's further simplified off by late_combine which caused scan assembly
failure.
Move the definition of mask outside to
for the testcase in the PR115406, here is part of the dump.
char D.4882;
vector(1) _1;
vector(1) signed char _2;
char _5;
:
_1 = { -1 };
When assign { -1 } to vector(1} {signed-boolean:8},
Since TYPE_PRECISION (itype) <= BITS_PER_UNIT, so it set each bit of dest
with each vector el
gcc/ChangeLog:
PR target/115517
* config/i386/mmx.md (vcondv2sf): Removed.
(vcond): Ditto.
(vcond): Ditto.
(vcondu): Ditto.
(vcondu): Ditto.
* config/i386/sse.md (vcond): Ditto.
(vcond): Ditto.
(vcond): Ditto.
(vcond):
> Richard suggests that we implement the "obvious" transforms like
> inversion in the middle-end but if for example unsigned compares
> are not supported the us_minus + eq + negative trick isn't on
> that list.
>
> The main reason to restrict vec_cmp would be to avoid
> a <= b ? c : d going with an
gcc/ChangeLog
PR target/115517
* config/i386/sse.md
(*_cvtmask2_not): New pre_reload
splitter.
(*_cvtmask2_not): Ditto.
(*avx2_pcmp3_6): Ditto.
(*avx2_pcmp3_7): Ditto.
---
gcc/config/i386/sse.md | 97 ++
gcc/ChangeLog:
PR target/115517
* config/i386/sse.md
(*_movmsk_lt_avx512): New
define_insn_and_split.
(*_movmsk_ext_lt_avx512):
Ditto.
(*_pmovmskb_lt_avx512): Ditto.
(*_pmovmskb_zext_lt_avx512): Ditto.
(*sse2_pmovmskb_ext_lt_a
Try to optimize x < 0 ? -1 : 0 into (signed) x >> 31
and x < 0 ? 1 : 0 into (unsigned) x >> 31.
Add define_insn_and_split for the optimization did in
ix86_expand_int_vcond.
gcc/ChangeLog:
PR target/115517
* config/i386/sse.md ("*ashr3_1"): New
define_insn_and_split.
1 - 100 of 611 matches
Mail list logo
