So Richard S. noticed 3 issues in the V1 patch. Specifically it should have
been using rtx_equal_p rather than just testing pointer equality. That's not a
correctness issue, but could potentially allow the pattern to apply more often.
Second we should be checking for !side_effects_p on the operand we're dropping.
Easy to fix.
Finally there was a const0_rtx use that should have been CONST0_RTX. Given how
often I mention that one to others, I'm embarrassed I missed it.
Bootstrapped on x86 and retested on the various embedded platforms. Bootstraps
on riscv platforms, aarch64, armv7 and sh4eb are in flight.
--
So this is derived from S_regmatch in spec2017, so fairly hot.
long
frob (unsigned short *y, long z)
{
long ret = (*y << 2) + z;
if (ret != z)
return 0;
return ret;
}
It generates this code on riscv:
lhu a5,0(a0)
sh2add a5,a5,a1
sub a1,a1,a5
czero.nez a0,a5,a1
ret
That's not bad, but the sh2add and sub are not actually needed. This may look
familiar to a case Daniel was recently discussing, the major difference are the
types of the function args which I got wrong the first time I reduced this
case.
czero instructions check their condition for zero/nonzero status. So we just
need to know if a1 has a zero/nonzero value at the czero instruction. So
working backwards:
a1 = a1 - a5 // sub instruction
a1 = a1 - ((a5 << 2) + a1) // substitute from sh2add
a1 = a5 << 2 // a1 terms cancel out
So we just need the nonzero state of a5 << 2. Now since a5 was set by the lhu
instruction, the upper 48 bits are already known zero, so critically we know
the upper 2 bits are zero. Meaning that we can just test a5 as set by the lhu
instruction for zero/nonzero. The net is we can generate this code instead:
lhu a0,0(a0)
czero.nez a0,a1,a0
ret
It's a small, but visible instruction count savings and likely a small
performance improvement on most designs.
So the trick to get there is a small simplify-rtx improvement. We just need to
simplify
(eq/ne (plus (x) (y)) (y)) -> (eq/ne (x) (0))
And all the right things just happen. Bootstrapped and regression tested on a
variety of native platforms including x86, aarch64, riscv and tested across the
various embedded targets in my tester. I'll wait for the RISC-V pre-commit CI
tester to render a verdict before going forward.
PR rtl-optimization/124766
gcc/
* simplify-rtx.cc (simplify_context::simplify_relational_operation_1):
Simplify x + y == y constructs.
gcc/testsuite/
* gcc.target/riscv/pr124766.c: New test.
When B is known to be non-negative and A > B, A must be positive,
so ABS(A) == A. The whole expression (A > B ? ABS(A) : B) then
simplifies to MAX(A, B). This is caught at -O2 via VRP, but at
-O1 phiopt1 produces ABS_EXPR and no later pass simplifies it.
PR tree-optimization/116700
gcc/ChangeLog:
* match.pd: (A > B ? ABS(A) : B -> MAX(A, B)): New pattern
for non-negative B.
gcc/testsuite/ChangeLog:
* gcc.dg/pr116700.c: New test.
* gcc.dg/tree-ssa/phi-opt-48.c: New test.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Based on patch by GitHub user ofats.
* elf.c (elf_zstd_decompress_frame): New static function,
broken out of elf_zstd_decompress.
(elf_zstd_decompress): Call elf_zstd_decompress_frame in a loop.
* zstdtest.c (test_large): Compress the file in chunks.
rtype here is only needed for POINTER_PLUS_EXPR and is only used
in the condition for PPE, so move it to that scope instead.
Pushed as obvious after bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-chrec.cc (chrec_fold_plus_poly_poly): Move
rtype definition to right before the use.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Before r8-4233-g6ff16d19d26a41, we would print EXACT_DIV_EXPR as `(ceiling /)`
which is wrong. Now we print it as `unknown operator` which is also wrong.
Printing it as `/` is correct here since it is the similar to `FLOOR_DIV_EXPR`
except it is undefined behavior if it is not exact (so floor is fine :)).
This shows up when printing out the reason why the following is not a contexpr:
constexpr int (*p1)[0] = 0, (*p2)[0] = 0;
constexpr int k2 = p2 - p1;
Bootstrapped and tested on x86_64-linux-gnu.
PR c++/119567
gcc/cp/ChangeLog:
* error.cc (dump_expr): Treat EXACT_DIV_EXPR the same as FLOOR_DIV_EXPR.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
The FreeBSD-specific subunit has not been adjusted to the renaming.
gcc/ada/
PR ada/125168
* libgnat/s-dorepr__freebsd.adb (Two_Prod): Adjust to renaming.
(Two_Sqr): Likewise.
simplify_count_zeroes validates DeBruijn CLZ tables by computing
(1 << (data + 1)) - 1 to simulate the value produced by the OR-cascade
b |= b >> 1; ... b |= b >> 32. For 64-bit input with data == 63 (the
MSB bit), data + 1 equals HOST_BITS_PER_WIDE_INT, making the shift
(HOST_WIDE_INT_1U << 64) undefined behavior. Hosts typically produce
0, so the check (0 * magic) >> 58 == 63 fails and check_table_array
returns false.
Every well-formed 64-bit DeBruijn CLZ table has an entry mapping the
all-ones value to bit 63, so this UB rejected every such table --
including the magic 0x03f79d71b4cb0a89 used in Stockfish's msb(),
zstd's bits.h, and cpython's pycore_bitutils.h.
Fix by special-casing data + 1 == HOST_BITS_PER_WIDE_INT to use
HOST_WIDE_INT_M1U. Only the 64-bit CLZ path is affected.
gcc/ChangeLog:
PR tree-optimization/122569
* tree-ssa-forwprop.cc (simplify_count_zeroes): Avoid
shift-by-HOST_BITS_PER_WIDE_INT UB when computing the all-ones
value for the CLZ validator.
gcc/testsuite/ChangeLog:
PR tree-optimization/122569
* gcc.dg/tree-ssa/pr122569-1.c: New test.
* gcc.dg/tree-ssa/pr122569-2.c: New test.
So this was something I noticed a while back, I'm pretty sure while throwing
hot blocks into an LLM to see what the LLM thought might be optimizable. In
this case it was mcf from spec2017.
So the basic idea is for code like this:
int foo(int x, int y) { return (y < x) ? 1 : -1; }
We get something like this for rv64gcbv_zicond:
slt a1,a1,a0 # 27 [c=4 l=4] slt_didi3
li a5,2 # 28 [c=4 l=4] *movdi_64bit/1
czero.eqz a0,a5,a1 # 29 [c=4 l=4] *czero.eqz.didi
addi a0,a0,-1 # 17 [c=4 l=4] *adddi3/1
That's not bad, in particular it avoids a likely tough to predict conditional
branch. But we can do better.
Essentially the code is selecting between 1 and -1. So if we take the output
of the SLT (0/1) shift it left by one position (0/2), then subtract one we get
a select for -1, 1.
After this patch we get the expected:
slt a1,a1,a0 # 28 [c=4 l=4] slt_didi3
slli a0,a1,1 # 29 [c=4 l=4] ashldi3
addi a0,a0,-1 # 17 [c=4 l=4] *adddi3/1
It's probably not any faster on a modern design, but it will encode more
efficiently, saving either 2 or 4 bytes (potentially improving performance by
getting more ops per fetch block). There's some very obvious
generalizations. We can select between 2^n and 0, we can select between 2^n-1
and -1. But we can also do things like select between 3, 5 or 9 and 0 (think
using shNadd where both source operands are the output of the slt). There's
all kinds of interesting possibilities here.
The key is to implement a splitter which handles 2^n and 0. Once that is in
place pre-existing code will handle the 2^n-1 and -1 case automatically. While
cases like selecting between 9 and 0 aren't yet handled, it would be a fairly
simple extension to these new splitters with the basic framework in place.
Anyway, while working on this I realized the scc_0 iterator didn't include
any_lt, which seems like a dreadful oversight on my part. So I fixed that as
well.
Given the high degree of non-orthogonality in the sCC capabilities of the
RISC-V ISA, this is actually several splitters to deal with the different cases
of sCC we can handle in a single instruction.
Tested on riscv32-elf and riscv64-elf. Will wait for pre-commit CI before
moving forward.
PR target/124009
gcc/
* config/riscv/iterators.md (scc_0): Add any_lt.
* config/riscv/zicond.md: Add splitters to select between 2^n and 0.
gcc/testsuite/
* gcc.target/riscv/pr124009.c: New test.
We define this macro after including the systems limits.h header which
may define this macro. Using glibc-2.43, for example, before this patch
every file that included limits.h would emit a warning if
-Wsystem-headers was in use.
PR c/125161
gcc/
* glimits.h (__STDC_VERSION_LIMITS_H__): Only define the macro
if it was not already defined.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
This is a trivial oversight in the recently added improvement to conditional
move generation on the RISC-V port.
We have a step which canonicalizes the comparison operands. The process of
canonicalizing may change one or both operands, including giving a new pseudo
with a different mode.
The new code failed to account for that and as a result it was using a stale
mode (QI) which caused all kinds of problems later. Just swapping the code
which canonicalizes the operand with the code that extracts the mode and
everything is happy again. Fixed a formatting nit while I was in there.
Tested on riscv32-elf and riscv64-elf. But waiting for pre-commit CI to do its
thing.
PR target/125152
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Extract the
mode after operand canonicalization.
gcc/testsuite/
* gcc.target/riscv/pr125152.c: New test.
In some misguided attempt at "cleanup", Google Cloud has
decided to retire 'gsutil' in favor of 'gcloud storage' instead
of leaving an entirely backwards-compatible wrapper so
that client scripts and muscle memory keep working.
In addition to breaking customers this way, they are also
sending AI bots around "cleaning up" old usages with scary
warnings that maybe the changes will break your entire world.
This is even more misguided, of course, and resulted in us
receiving CL 748661 (originally GitHub PR golang/gofrontend#13)
and then me receiving a private email asking for it to be merged.
It was easier to recreate the 4-line CL myself than to
enumerate everything that was wrong with that CL's
commit message.
I hope that only Google teams are being subjected to this.
This is based on https://go.dev/cl/748900 from the main Go repo by Russ.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/749000
I noticed while improving cselim-limited that if
not creating a new phi, there are a few empty basic blocks.
So this sets cfgcleanup when cselim-limited does
something in phiopt. cselim-5.c shows the case I
was looking into.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (pass_phiopt::execute): Set cfgcleanup
if cselim_limited returns true.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/cselim-5.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Move the logic to deduce what needs to be freed from the
caller to the callee by passing the OMP_LIST_... enum value
instead of multiple bool arguments to gfc_free_omp_namelist.
Additionally, add the name 'gfc_omp_list_type' to the existing
OMP_LIST_... enum values and OMP_LIST_NONE (== OMP_LIST_NUM)
as special value.
As an enum is available, use it properly and replace 0 by
OMP_LIST_FIRST in the list walks.
gcc/fortran/ChangeLog:
* gfortran.h (enum gfc_omp_list_type): Add this name
to the existing OMP_LIST... enum; add OMP_LIST_NONE.
(gfc_free_omp_namelist): Take that enum as arg instead of bool args.
* match.cc (gfc_free_omp_namelist): Update.
* openmp.cc (gfc_free_omp_clauses, gfc_free_omp_declare_variant_list,
gfc_match_omp_clause_reduction, gfc_match_omp_clauses,
gfc_match_omp_allocate, gfc_match_omp_flush,
gfc_match_omp_declare_target, resolve_omp_clauses,
gfc_resolve_omp_parallel_blocks, resolve_omp_do,
gfc_resolve_oacc_blocks, gfc_resolve_oacc_declare): Update
gfc_free_omp_namelist call and used enum type instead of
int.
* st.cc (gfc_free_statement): Likewise.
Co-Authored-By: Julian Brown <julian@codesourcery.com>
Consider this test from pr109038:
unsigned
foo (unsigned int a)
{
unsigned int b = a & 0x00FFFFFF;
unsigned int c = ((b & 0x000000FF) << 8
| (b & 0x0000FF00) << 8
| (b & 0x00FF0000) << 8
| (b & 0xFF000000) >> 24);
return c;
}
We currently generate something like this for rv64gcbv:
slli a0,a0,40
srli a0,a0,40
roriw a0,a0,24
ret
Two key points. The first two shifts clear the upper 40 bits. The roriw is a
rotation of the low 32 bits by 24 positions with a sign extension from bit 31
into bits 32..63.
So we're going to have bit 31 defining bits 32..63 after the rotation and the
low 8 bits will be clear. So we can just do
slliw a0,a0,8
Note that doesn't even strictly need bitmanip, though the original sequence
did. The mask is always going to be a consecutive run of on bits including
bits 31..63. The number of bits off in the mask must be 32 - rotate count.
Put it all together and you get a nice slliw.
Essentially it's a 3->1 combination, so a define_insn is sufficient.
An earlier version of this patch has been in my tester for weeks, so the usual
testing has been performed. But that version was meaningfully different (left
a trailing andi and was impemented as a splitter). So I consider most of that
testing invalid. This version did go through riscv32-elf and riscv64-elf
without regressions and I'll be waiting on the upstream pre-commit to render a
verdict.
PR target/109038
gcc/
* config/riscv/bitmanip.md (rotate_with_masking_to_shift): New pattern.
gcc/testsuite/
* gcc.target/riscv/pr109038.c: New test.
If these tests are linked as PIE, the linker ends up creating runtime
text relocation and warns or errors out.
gcc/testsuite/
PR testsuite/70150
* gcc.dg/ipa/pr122458.c (dg-options): Add -no-pie.
* gcc.dg/lto/toplevel-extended-asm-1_0.c (dg-lto-options): Add
-no-pie.
* gcc.dg/lto/toplevel-simple-asm-1_0.c (dg-lto-options): Add
-no-pie.
These tests use check_function_bodies. Some of them expect a function
body that is not valid for PIE. Some have minor difference of
"1+sym(%rip)" vs "sym+1(%rip)". Others have extra "@PLT" in call
instructions.
gcc/testsuite/
PR testsuite/70150
* gcc.target/i386/builtin-memmove-13.c (dg-options): Add
-fno-pie.
* g++.target/i386/memset-pr108585-1a.C: Likewise.
* g++.target/i386/memset-pr108585-1b.C: Likewise.
* gcc.target/i386/memcpy-pr120683-2.c: Likewise.
* gcc.target/i386/memcpy-pr120683-3.c: Likewise.
* gcc.target/i386/memcpy-pr120683-4.c: Likewise.
* gcc.target/i386/memcpy-pr120683-5.c: Likewise.
* gcc.target/i386/memcpy-pr120683-6.c: Likewise.
* gcc.target/i386/memcpy-pr120683-7.c: Likewise.
* gcc.target/i386/memset-pr120683-13.c: Likewise.
* gcc.target/i386/memset-pr120683-17.c: Likewise.
* gcc.target/i386/memset-pr120683-18.c: Likewise.
* gcc.target/i386/memset-pr120683-19.c: Likewise.
* gcc.target/i386/memset-pr120683-20.c: Likewise.
* gcc.target/i386/memset-pr120683-21.c: Likewise.
* gcc.target/i386/memset-pr120683-22.c: Likewise.
* gcc.target/i386/memset-pr120683-23.c: Likewise.
* gcc.target/i386/pr111657-1.c: Likewise.
* gcc.target/i386/pr120881-2a.c: Likewise.
Adding the comment that regenerate-opt-urls produced.
I will add docs in a future patch. This is just to make the CI happy in
the mean time.
gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Add temp fix for -mmpy-option.
Signed-off-by: Michiel Derhaeg <michiel@synopsys.com>
Clock calls on VxWorks are slow, so the odds that the consecutive
calls of *clock::now() will yield a different result are not
negligible. Reordering the calls avoids false positives.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/semaphore/try_acquire_until.cc
(test01): Reorder calls.
This pattern does not work for vector types as written. To make it work we need to
create a vec_duplicate of the `bool` value. I am not sure that is better so for
right now this just enables the pattern only for INTEGRAL_TYPE_P types (which means
non-vectors).
Pushed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/125139
gcc/ChangeLog:
* match.pd (`(A>>bool) EQ 0 -> (unsigned)A LE bool`): Enable
only for INTEGRAL_TYPE_P types.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr125139-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
This typo was breaking compiling for Windows (which of course, uses .exe
extension)
gcc/algol68/ChangeLog:
* Make-lang.in: Correct typo exeect -> exeext
Also add its counterpart:
"(A>>bool) != 0 -> (unsigned)A) > bool"
Changes from v2:
- gate the pattern with "#if GIMPLE"
- use 'single_use' in the rshift result
- add the NE variant
- v2 link: https://gcc.gnu.org/pipermail/gcc-patches/2026-April/712431.html
Bootstrap tested in x86, aarch64 and RISC-V.
Regression tested in x86 and aarch64.
PR tree-optimization/119420
gcc/ChangeLog
* match.pd(`(A>>bool) EQ 0 -> (unsigned)A LE bool`): New
pattern.
gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/pr119420.c: New test.
We have an instance in Perlbench of a code that if a condition is true a
bit is set, if false the same bit is cleared. This can be made
unconditional by always running the bit clear, and then run the bit_ior
with the result of (cond) * CST1:
(a & ~CST1) | (cond * CST1)
If "cond" is false (zero) the bit_ior is a no-op and the bit will remain
cleared, if "cond" is true we'll set the bit as intended.
Note that the transformation will add a mult into the pattern, therefore
make it valid only if type <= word_size to avoid wide int
multiplications.
Bootstrapped on x86, aarch64 and rv64.
Regression tested on x86 and aarch64.
PR rtl-optimization/123967
gcc/ChangeLog:
* match.pd(`if (cond) (A | CST1) : (A & ~CST1)`)`: New pattern.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr123967-2.c: New test.
* gcc.dg/tree-ssa/pr123967-3.c: New test.
* gcc.dg/tree-ssa/pr123967.c: New test.
When there are multiple declarators in a declaration and the type
is specified via typeof, an expression inside the argument of
typeof may be evaluated multiple times. Fix this by adding a
save expression.
PR c/124576
gcc/c/ChangeLog:
* c-decl.cc (declspecs_add_type): Add save_expr.
gcc/testsuite/ChangeLog:
* gcc.dg/pr124576.c: New test.
Also adding the variant "(A>>C) == (B>>C) -> (A^B) < (1<<C)"
Bootstrapped on x86, aarch64 and rv64.
Regression tested on x86 and aarch64.
Changes from v2:
- add type_has_mode_precision_p () check
- add types_match() to simplify types comparison
- add rshift operand checks (must not be negative, must not
surpass type size)
- v2 link: https://gcc.gnu.org/pipermail/gcc-patches/2026-March/711284.html
PR tree-optimization/110010
gcc/ChangeLog:
* match.pd (`(A>>C) NE|EQ (B>>C) -> (A^B) GE|LT (1<<C)`): New
pattern.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr110010.c: New test.
A default was set in the `"${build}" != "${host}"` case, but not in the
`"${build}" = "${host}"` case.
For a working build, this change should not make any difference. CPP_FOR_BUILD
is passed to build modules as CPP. If not set, autoconf macro AC_PROG_CC infers
CPP by trying various programs. First, it tries "$CC -E", which CPP will
default to in all cases with this patch.
The following command produces the same build directory with and without the
patch:
./configure --build=x86_64-make_autoconf_enable_cross_compiling-linux-gnu --host=x86_64-linux-gnu
The following command produces a Makefile containing `CPP_FOR_BUILD = ` without
the patch and containing `CPP_FOR_BUILD = $(CC_FOR_BUILD) -E` with the patch:
./configure
ChangeLog:
* configure.ac: Set default for CPP_FOR_BUILD environment variable in all cases.
* configure: Regenerate.
Signed-off-by: Manuel Jacob <me@manueljacob.de>
They were preserved in the `"${build}" != "${host}"` case, but not in the
`"${build}" = "${host}"` case.
Each of the following commands produces the same build directory with and
without the patch:
./configure --build=x86_64-make_autoconf_enable_cross_compiling-linux-gnu --host=x86_64-linux-gnu
CC_FOR_BUILD=/tmp/gcc_for_build ./configure --build=x86_64-make_autoconf_enable_cross_compiling-linux-gnu --host=x86_64-linux-gnu
./configure
The following command produces a Makefile containing `CC_FOR_BUILD = $(CC)`
without the patch and containing `CC_FOR_BUILD = /tmp/gcc_for_build` with the
patch:
CC_FOR_BUILD=/tmp/gcc_for_build ./configure
ChangeLog:
* configure.ac: Preserve *_FOR_BUILD environment variables in all cases.
* configure: Regenerate.
Signed-off-by: Manuel Jacob <me@manueljacob.de>
Here when streaming in view_interface<int>::data() and merging it with
the in-TU version, we find that the streamed-in version already has its
noexcept instantiated _and_ its return type deduced. is_matching_decl
has logic to update the in-TU version when that is the case, first by
propagating the instantiated noexcept. But this is done by overwriting
the entire function type with the streamed-in one, which simultaneously
updates the return type as well. This premature return type updating
breaks the later deduced return type checks which are partially in terms
of the original function type.
This patch fixes this by propagating the instantiated noexcept more
narrowly via build_exception_variant. Also turn e_type into a
reference so that it's not stale after updating e_inner's TREE_TYPE.
PR c++/125115
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Turn e_type into a
reference and use it instead of TREE_TYPE (e_inner). Always
use build_exception_variant to propagate an already-instantiated
noexcept.
gcc/testsuite/ChangeLog:
* g++.dg/modules/auto-9.h: New test.
* g++.dg/modules/auto-9_a.H: New test.
* g++.dg/modules/auto-9_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Simple non-functional change.
I'm planning to add many more cases to riscv_macro_fusion_pair_p so it
is moved to a separate source file to prevent riscv.cc from becoming
too unwieldy.
Also added some tests to verify the cases that are actually tied to
mtunes present upstream. Unfortunately, many of them are not.
Regtested for rv32gc & rv64gc with the new tests included in the baseline.
gcc/ChangeLog:
* config.gcc: Added riscv-fusion.o
* config/riscv/riscv-protos.h (enum riscv_fusion_pairs):
(riscv_macro_fusion_p): Added declaration.
(riscv_macro_fusion_pair_p): Idem.
(riscv_get_fusible_ops): Idem.
* config/riscv/riscv.cc (enum riscv_fusion_pairs):
(riscv_macro_fusion_p): Moved to riscv-fusion.cc
(riscv_fusion_enabled_p): Idem.
(riscv_set_is_add): Idem.
(riscv_set_is_addi): Idem.
(riscv_set_is_adduw): Idem.
(riscv_set_is_shNadd): Idem.
(riscv_set_is_shNadduw): Idem.
(riscv_macro_fusion_pair_p): Idem.
(riscv_get_fusible_ops): New function to access tune_param->fusible_ops
from riscv-fusion.cc.
* config/riscv/t-riscv: Added riscv-fusion.cc
* config/riscv/riscv-fusion.cc: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fusion-auipc-addi.c: New test.
* gcc.target/riscv/fusion-lui-addi.c: New test.
* gcc.target/riscv/fusion-zexth.c: New test.
* gcc.target/riscv/fusion-zextw.c: New test.
Signed-off-by: Michiel Derhaeg <michiel@synopsys.com>
Commit r17-203 caused significant increase in GCC build time
on several environments as folks reported, mainly due to
excessively long execution time of genautomata.
As Alexander pointed out, the current division modeling in
c86-4g*.md can cause a combinatorial explosion in the
automaton, that further leads to significant build time
increase.
Following Alexander's suggestion, this patch introduces the
dedicated automatons and cpu_units for idiv and fdiv, uses
them to updates the integer, floating point division and
square root modeling for now. Some evaluated statistics
are listed below.
With r17-202:
*Tested stage-1 i686 build -j 32: 255 seconds*
$ nm -CS -t d --defined-only gcc/insn-automata.o \
| sed 's/^[0-9]* 0*//' \
| sort -n | tail -20
13896 r slm_transitions
15360 r znver4_fp_store_transitions
16760 r znver4_ieu_transitions
17776 r bdver1_ieu_transitions
20068 r bdver1_fp_check
20068 r bdver1_fp_transitions
20983 t internal_state_transition(int, DFA_chip*)
22270 t internal_min_issue_delay(int, DFA_chip*)
26208 r slm_min_issue_delay
27244 r bdver1_fp_min_issue_delay
28518 r glm_check
28518 r glm_transitions
33690 r geode_min_issue_delay
45436 r znver4_fpu_min_issue_delay
46980 r bdver3_fp_min_issue_delay
49428 r glm_min_issue_delay
53730 r btver2_fp_min_issue_delay
53760 r znver1_fp_transitions
93960 r bdver3_fp_transitions
181744 r znver4_fpu_transitions
With culprit commit r17-203:
*Tested stage-1 i686 build -j 32: 949 seconds*
$ nm -CS -t d --defined-only gcc/insn-automata.o \
| sed 's/^[0-9]* 0*//' \
| sort -n | tail -20
28518 r glm_check
28518 r glm_transitions
33690 r geode_min_issue_delay
45436 r znver4_fpu_min_issue_delay
46980 r bdver3_fp_min_issue_delay
49428 r glm_min_issue_delay
53730 r btver2_fp_min_issue_delay
53760 r znver1_fp_transitions
68160 r c86_4g_ieu_min_issue_delay
93960 r bdver3_fp_transitions
110080 r c86_4g_fp_min_issue_delay
136320 r c86_4g_ieu_transitions
181744 r znver4_fpu_transitions
220160 r c86_4g_fp_transitions
262988 r c86_4g_m7_fpu_base
475225 r c86_4g_m7_ieu_min_issue_delay
950450 r c86_4g_m7_ieu_transitions
4010567 r c86_4g_m7_fpu_min_issue_delay
5496908 r c86_4g_m7_fpu_check
5496908 r c86_4g_m7_fpu_transitions
With this patch:
*Tested stage-1 i686 build -j 32: 257 seconds*
$ nm -CS -t d --defined-only gcc/insn-automata.o \
| sed 's/^[0-9]* 0*//' \
| sort -n | tail -20
20068 r bdver1_fp_transitions
22354 r c86_4g_m7_ieu_min_issue_delay
25705 t internal_state_transition(int, DFA_chip*)
26208 r slm_min_issue_delay
27164 t internal_min_issue_delay(int, DFA_chip*)
27244 r bdver1_fp_min_issue_delay
28518 r glm_check
28518 r glm_transitions
33690 r geode_min_issue_delay
33728 r c86_4g_fp_transitions
45436 r znver4_fpu_min_issue_delay
46980 r bdver3_fp_min_issue_delay
49428 r glm_min_issue_delay
53730 r btver2_fp_min_issue_delay
53760 r znver1_fp_transitions
89414 r c86_4g_m7_ieu_transitions
93960 r bdver3_fp_transitions
181744 r znver4_fpu_transitions
326322 r c86_4g_m7_fpu_min_issue_delay
1305288 r c86_4g_m7_fpu_transitions
I noticed the number of c86_4g_m7_fpu_transitions is still
large, but this patch can address the build time issue.
To avoid impacting folks' daily builds and regular testings,
I'd like to land this patch first if possible. We can then further
refine the c86-4g modeling and investigate large transition
count as part of the follow-up work, even potentially part
of PR 87832.
gcc/ChangeLog:
* config/i386/c86-4g-m7.md (c86_4g_m7_idiv): New automaton.
(c86_4g_m7_fdiv): Ditto.
(c86-4g-m7-idiv): New unit.
(c86-4g-m7-fdiv): Ditto.
(c86_4g_m7_idiv_DI): Adjust unit in the reservation.
(c86_4g_m7_idiv_SI): Ditto.
(c86_4g_m7_idiv_HI): Ditto.
(c86_4g_m7_idiv_QI): Ditto.
(c86_4g_m7_idiv_DI_load): Ditto.
(c86_4g_m7_idiv_SI_load): Ditto.
(c86_4g_m7_idiv_HI_load): Ditto.
(c86_4g_m7_idiv_QI_load): Ditto.
(c86_4g_m7_fp_div): Ditto.
(c86_4g_m7_fp_div_load): Ditto.
(c86_4g_m7_fp_idiv_load): Ditto.
(c86_4g_m7_avx512_ssediv): Ditto.
(c86_4g_m7_avx512_ssediv_mem): Ditto.
(c86_4g_m7_avx512_ssediv_z): Ditto.
(c86_4g_m7_avx512_ssediv_zmem): Ditto.
(c86_4g_m7_avx512_sse_sqrt): Ditto.
(c86_4g_m7_avx512_sse_sqrt_load): Ditto.
(c86_4g_m7_fp_sqrt): Ditto. Rename from ...
(c86_4g_m7fp_sqrt): ... here.
* config/i386/c86-4g.md (c86_4g_idiv): New automaton.
(c86_4g_fdiv): Ditto.
(c86-4g-idiv): New unit.
(c86-4g-fdiv): Ditto.
(c86_4g_idiv_DI): Ditto.
(c86_4g_idiv_SI): Ditto.
(c86_4g_idiv_HI): Ditto.
(c86_4g_idiv_QI): Ditto.
(c86_4g_idiv_mem_DI): Ditto.
(c86_4g_idiv_mem_SI): Ditto.
(c86_4g_idiv_mem_HI): Ditto.
(c86_4g_idiv_mem_QI): Ditto.
(c86_4g_fp_sqrt): Ditto.
(c86_4g_sse_sqrt_sf): Ditto.
(c86_4g_sse_sqrt_sf_mem): Ditto.
(c86_4g_sse_sqrt_df): Ditto.
(c86_4g_sse_sqrt_df_mem): Ditto.
(c86_4g_fp_op_div): Ditto.
(c86_4g_fp_op_div_load): Ditto.
(c86_4g_fp_op_idiv_load): Ditto.
(c86_4g_ssediv_ss_ps): Ditto.
(c86_4g_ssediv_ss_ps_load): Ditto.
(c86_4g_ssediv_ss_pd): Ditto.
(c86_4g_ssediv_ss_pd_load): Ditto.
(c86_4g_ssediv_avx256_ps): Ditto.
(c86_4g_ssediv_avx256_ps_load): Ditto.
(c86_4g_ssediv_avx256_pd): Ditto.
(c86_4g_ssediv_avx256_pd_load): Ditto.
Signed-off-by: Kewen Lin <linkewen@hygon.cn>
This patch introduces the pipeline description for the Synopsys RMX-100 series
processor to the RISC-V GCC backend. The RMX-100 has a short, three-stage,
in-order execution pipeline with configurable multiply unit options.
The option -mmpy-option was added to control which version of the MPY unit the
core has and what the latency of multiply instructions should be similar to
ARCv2 cores (see gcc/config/arc/arc.opt:60).
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add arc-v-rmx-100-series.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type):
Add arcv_rmx100.
(enum arcv_mpy_option_enum): New enum for ARC-V multiply options.
* config/riscv/riscv-protos.h (arcv_mpy_1c_bypass_p): New declaration.
(arcv_mpy_2c_bypass_p): New declaration.
(arcv_mpy_10c_bypass_p): New declaration.
* config/riscv/riscv.cc (arcv_mpy_1c_bypass_p): New function.
(arcv_mpy_2c_bypass_p): New function.
(arcv_mpy_10c_bypass_p): New function.
* config/riscv/riscv.md: Add arcv_rmx100.
* config/riscv/riscv.opt: New option for RMX-100 multiply unit
configuration.
* doc/riscv-mtune.texi: Document arc-v-rmx-100-series.
* config/riscv/arcv-rmx100.md: New file.
Co-authored-by: Artemiy Volkov <artemiyv@acm.org>
Co-authored-by: Luis Silva <luiss@synopsys.com>
Signed-off-by: Michiel Derhaeg <michiel@synopsys.com>
This patch introduces the pipeline description for the Synopsys RHX-100 series
processor to the RISC-V GCC backend. The RHX-100 features a 10-stage,
dual-issue, in-order execution pipeline architecture.
It has support for instruction fusion, which will be addressed by subsequent
patches. Due to fusion, up to four instructions can be issued in a single
cycle. It is modeled as four separate pipelines and the issue_rate is set to
four.
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add arc-v-rhx-100-series.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type): Add
arcv_rhx100.
* config/riscv/riscv.cc (arcv_rhx100_tune_info): New riscv_tune_param.
* config/riscv/riscv.md: Add arcv_rhx100 to tune attribute.
* doc/riscv-mtune.texi: Add RHX-100 documentation.
* config/riscv/arcv-rhx100.md: New file.
Co-authored-by: Artemiy Volkov <artemiyv@acm.org>
Co-authored-by: Luis Silva <luiss@synopsys.com>
Signed-off-by: Michiel Derhaeg <michiel@synopsys.com>
In riscv_expand_conditional_move, detect unsigned comparisons against
power-of-2 boundaries and convert them to shift-based equality tests.
This avoids materializing large constants (e.g. 2^56 - 1) that may
require multiple instructions (bseti + sltu), replacing them with a
single srli that feeds directly into czero.eqz/czero.nez.
The transformation handles four cases:
GTU x, (2^N-1) -> NE (x >> N), 0
LEU x, (2^N-1) -> EQ (x >> N), 0
GEU x, 2^N -> NE (x >> N), 0
LTU x, 2^N -> EQ (x >> N), 0
For example, `(a & (0xff << 56)) ? b : 0` previously generated:
bseti a5, zero, 56
sltu a0, a0, a5
czero.nez a0, a1, a0
Now generates:
srli a0, a0, 56
czero.eqz a0, a1, a0
Existing define_split patterns in riscv.md (lines 3727-3748) handle
the same optimization for standalone SCC operations, but they don't
fire in the conditional move expansion path which goes through
riscv_expand_int_scc directly.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move):
Convert unsigned comparisons against power-of-2 boundaries
to shift-based equality tests.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-shift-cond.c: New test.
tsubst_splice_scope isn't propagating cv-quals from the template tree
to the result, which means wrongly failed asserts in the new test due to
a missing 'const'. So let's add the cv-quals like we do in so many
other places in tsubst.
PR c++/125096
gcc/cp/ChangeLog:
* pt.cc (tsubst_splice_scope): Don't return early for
dependent_splice_p. Propagate cv-qualifiers from the
SPLICE_SCOPE to the result.
* reflect.cc (valid_splice_scope_p): Accept SPLICE_SCOPE.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/mangle4.C: Move dg-error.
* g++.dg/reflect/dep16.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Several of the gas and gnu_ld checks in gcc/configure actually need to
determine if Solaris as and ld are in use. Since solaris_as and
solaris_ld are determined reliably now, it's clearer to check them
directly instead of !gas and !gnu_ld.
This patch does just that. Since solaris_as/solaris_ld imply target
*-*-solaris2*, the tests can be simplified and sometimes converted from
case/esac to if/else.
Bootstrapped on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11,
x86_64-pc-linux-gnu, amd64-pc-freebsd15.0, and
x86_64-apple-darwin21.6.0.
When there are different flavours of as and/or ld depending on PATH
(/usr/bin/as vs. /usr/gnu/bin/as resp. ld on Solaris, /usr/bin/ld, LLD,
and /usr/local/bin/ld, GNU ld on FreeBSD), the builds were configured
with --with-as/--with-ld.
The Solaris tests were run for as/ld, gas/ld, and gas/gld
configurations, the FreeBSD tests with gas/gld.
In all cases, gcc/auto-host.h and gcc/Makefile were unchanged.
2026-02-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* configure.ac: Test solaris_as, solaris_ld instead of gas, gnu_ld.
(gcc_cv_as_working_gdwarf_n_flag): Escape '.' in filename.
* acinclude.m4 (gcc_cv_initfini_array): Test solaris_as,
solaris_ld instead of gas, gnu_ld.
* configure: Regenerate.
The AND case in riscv_rtx_costs for the slli.uw pattern (zba extension) has a
multi-statement if body without braces. This causes the 'return true' to
execute unconditionally whenever the left operand of AND is an ASHIFT,
regardless of whether the inner condition (checking register_operand,
CONST_INT_P, and the 0xffffffff mask) is satisfied.
This effectively short-circuits the entire AND cost calculation for any
AND+ASHIFT combination when TARGET_ZBA && TARGET_64BIT && DImode,
skipping subsequent pattern checks (bclri, bclr, etc.) and the
fallthrough to PLUS/MINUS.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_rtx_costs): Add missing braces
around the if body for the slli.uw pattern in the AND case.
As the following testcase shows, we have two different transformations
of __strcat_chk. One done in strlen_pass::handle_builtin_strcat,
which transforms __strcat_chk (x, y, z) if we know beforehand strlen (x),
so something like:
l = strlen (x);
__strcat_chk (x, y, z);
and since PR87672 we change that to
l = strlen (x);
__strcpy_chk (x + l, y, z - l);
i.e. decrease the objsz in
if (objsz)
{
objsz = fold_build2_loc (loc, MINUS_EXPR, TREE_TYPE (objsz), objsz,
fold_convert_loc (loc, TREE_TYPE (objsz),
unshare_expr (dstlen)));
objsz = force_gimple_operand_gsi (&m_gsi, objsz, true, NULL_TREE, true,
GSI_SAME_STMT);
}
And another transformation is when we have earlier __strcat_chk (x, y, z)
call and want to compute strlen (x) after that. In that case
get_string_length transforms
__strcat_chk (x, y, z);
to
t = strlen (x);
l = __stpcpy_chk (x + t, y, z) - x;
where l is the len we are looking for. This patch changes it similarly to
the PR87672 to
t = strlen (x);
l = __stpcpy_chk (x + t, y, z - t) - x;
instead.
2026-05-01 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/125079
* tree-ssa-strlen.cc (get_string_length): Transform
__strcat_chk (x, y, z) when we need strlen (x) afterwards into
l1 = strlen (x); l = __stpcpy_chk (x + l1, y, z - l1) - x;
where l is the strlen (x), instead of using z as last __stpcpy_chk
argument.
* gcc.dg/strlenopt-97.c: New test.
Reviewed-by: Richard Biener <rguenth@suse.de>
So this is a trivial little bug we found doing some comparisons against LLVM.
For the function sub2 in load-immediate.c we get this code:
li a5,-32768
sh a5,0(a0)
xori a5,a5,-1
sh a5,0(a1)
Note carefully that li+xori. There's a slightly better sequence here from an
encoding standpoint. Instead of using xori we can adjust the synthesis
sequence to target an "addi" for that statement and in doing so we can save two
code bytes of space.
The xori sequence was used because we can't do this in gcc:
(set (dest:HI) (const_int 0x8000))
We're in HI mode so the constant must be sign extended from bit 15 to a
HOST_WIDE_INT.
Fixing this isn't hard. The key is realizing the vast majority of the time we
really don't want/need to load in HImode and in fact we're typically going to
be generating objects in word_mode. So instead of passing in the pre-promoted
mode, pass in the post-promoted mode.
That's fine and good with one caveat. CSE fails to use NEG/NOT to derive a
new constant from an older constant, even if the cost is smaller, which caused
a code quality regression elsewhere on the RISC-V port. So this patch adjusts
CSE ever-so-slightly to allow it to derive constants from a previous constant
using NOT/NEG in a fairly obvious way.
This has been in my tester for a while, so it's been through the usual
bootstrap & regression test on the Pioneer, BPI, x86 and aarch64 and others as
well as testing across the various embedded targets.
Waiting on pre-commit testing to do its thing.
PR target/124559
gcc/
* config/riscv/riscv-protos.h (riscv_move_integer): Drop mode argument.
* config/riscv/riscv.cc (riscv_move_integer): Pass mode after promotions
to riscv_build_integer. All callers changed.
* config/riscv/riscv.md: Corresponding changes.
* cse.cc (cse_insn): Try to derive one constant from another using NOT/NEG.
I noticed that Doxygen was not documenting the contents of
<experimental/simd> as part of namespace std, because it didn't know
about the _GLIBCXX_SIMD_BEGIN_NAMESPACE and _GLIBCXX_SIMD_END_NAMESPACE
macros which open and close namespace std::experimental::parallelism_v2.
After defining those macros in the Doxygen config, the Doxygen comments
in experimental/bits/simd.h were causing namespace std to be documented
as part of the Parallelism TS v2. That's because the preprocessed code
looks like:
/** @ingroup ts_simd
* @{
*/
namespace std::experimental::inline parallelism_v2 {
This causes Doxygen to apply the @ingroup command to all three of
namespace std, namespace std::experimental, and namespace
std::experimental::parallelism_v2. I don't know if this is the intended
behaviour, but it doesn't seem useful so I've opened an issue about it:
https://github.com/doxygen/doxygen/issues/12114
To workaround this, we can move the _GLIBCXX_SIMD_BEGIN_NAMESPACE macro
before the @{ group and document it separately with a @namespace
comment. That makes the @ingroup only apply to the namespace named by
the @namespace command, not to its enclosing namespaces as well. Moving
the position of the BEGIN macro also fixes the nesting, as previously we
had @{ then BEGIN then @} then END. Now we have BEGIN @{ @} END which
seems preferable.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (PREDEFINED): Add BEGIN/END macros for
the <experimental/simd> namespace.
* include/experimental/bits/simd.h: Move BEGIN macro before
Doxygen @{ group.
Use markdown and suppress unwanted docs for internal helpers.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h: Prevent Doxygen from documenting
namespace __detail as part of the Iterators topic.
* include/bits/stl_iterator_base_funcs.h: Likewise. Also mark
internal helpers as undocumented.
(distance, advance): Improve Doxygen comments.
* include/bits/stl_iterator_base_types.h (iterator): Use
markdown in Doxygen comment. Add @deprecated.
(iterator_traits): Improve wording of Doxygen comment.
The ranges::sample and ranges::shuffle algorithms are supposed to work
with types which model std::uniform_random_bit_generator, which means
they should not assume that G::result_type is present. That isn't needed
to satisfy the concept. Change the algorithms to use decltype(__g())
instead of using result_type.
This isn't sufficient to fix the bug though, because those algorithms
use std::uniform_int_distribution and that class template's operator()
overloads depend on the more restrictive uniform random bit generator
requirements, which do include the presence of a nested result_type
member.
We need to change std::uniform_int_distribution to also use decltype
instead of the nested result_type, even though the standard says that
std::uniform_int_distribution is allowed to assume that result_type
exists.
There's yet another problem, which is that a type that returns random
bool values can model the concept, but doesn't meet the named
requirements and can't be used with std::uniform_int_distribution. That
isn't addressed by this change.
libstdc++-v3/ChangeLog:
PR libstdc++/121919
* include/bits/ranges_algo.h (__sample_fn, __shuffle_fn): Use
decltype(__g()) instead of remove_reference_t<_G>::result_type.
* include/bits/uniform_int_dist.h
(uniform_int_distribution::operator()): Use decltype(__urng())
instead of _UniformRandomBitGenerator::result_type
(uniform_int_distribution::__generate_impl): Likewise.
* testsuite/25_algorithms/sample/121919.cc: New test.
* testsuite/25_algorithms/shuffle/121919.cc: New test.
Reviewed-by: Nathan Myers <nmyers@redhat.com>
This changes gnatlink to append _pic to the name of the static Ada runtime
when -pie is passed on the command line.
gcc/ada/
PR ada/87936
* gnatlink.adb (Gnatlink): Rename local variable and add Output_PIE
local variable; when it is set, compile the binder file with -fPIE.
(Process_Args): Set Output_PIE upon seeing -pie.
(Process_Binder_File): Append "_pic" to the name of the static Ada
runtime if Output_PIE is set.
gcc/testsuite/
* gnat.dg/pie1.adb: New file.
