Martin Uecker [Sat, 30 Mar 2024 18:49:48 +0000 (19:49 +0100)]
C23: fix aliasing for structures/unions with incomplete types
When incomplete structure/union types are completed later, compatibility
of struct types that contain pointers to such types changes. When forming
equivalence classes for TYPE_CANONICAL, we therefor need to be conservative
and treat all structs with the same tag which are pointer targets as
equivalent for purposed of determining equivalency of structure/union
types which contain such types as member. This avoids having to update
TYPE_CANONICAL of such structure/unions recursively. The pointer types
themselves are updated in c_update_type_canonical.
gcc/c/
* c-typeck.cc (comptypes_internal): Add flag to track
whether a struct is the target of a pointer.
(tagged_types_tu_compatible): When forming equivalence
classes, treat nested pointed-to structs as equivalent.
gcc/testsuite/
* gcc.dg/c23-tag-incomplete-alias-1.c: New test.
YunQiang Su [Tue, 28 May 2024 18:28:25 +0000 (02:28 +0800)]
MIPS16: Mark $2/$3 as clobbered if GP is used
PR Target/84790.
The gp init sequence
li $2,%hi(_gp_disp)
addiu $3,$pc,%lo(_gp_disp)
sll $2,16
addu $2,$3
is generated directly in `mips_output_function_prologue`, and does
not appear in the RTL.
So the IRA/IPA passes are not aware that $2/$3 have been clobbered,
so they may be used for cross (local) function call.
Let's mark $2/$3 clobber both:
- Just after the UNSPEC_GP RTL of a function;
- Just after a function call.
Reported-by: Matthias Schiffer <mschiffer@universe-factory.net> Origin-Patch-by: Felix Fietkau <nbd@nbd.name>.
gcc
* config/mips/mips.cc(mips16_gp_pseudo_reg): Mark
MIPS16_PIC_TEMP and MIPS_PROLOGUE_TEMP clobbered.
(mips_emit_call_insn): Mark MIPS16_PIC_TEMP and
MIPS_PROLOGUE_TEMP clobbered if MIPS16 and CALL_CLOBBERED_GP.
[committed] [v2] More logical op simplifications in simplify-rtx.cc
does some simplifications, and then `bseli.b $w1,$w0,255` is found that
it is same with `or.v $w1,$w0,$w1`. So there will be no bseli.b instruction
generated.
Let's use 254 instead of 255 to test the generation of `bseli.b`.
gcc/testsuite
* gcc.target/mips/msa-builtins.c: Use 254 instead of 255 for
bseli.b, as `bseli.b $w0,$w1,255` is same as `or.v $w0,$w0,$w1`.
This patch fixes libgm2/libm2iso/wraptime.cc:InitTM so that
it does not always return NULL. The incorrect autoconf macro
was used (inside InitTM) and the function short circuited
to return NULL. The fix is to use HAVE_SYS_TIME_H and use
AC_HEADER_TIME in libgm2/configure.ac.
libgm2/ChangeLog:
PR modula2/115276
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use AC_HEADER_TIME.
* libm2iso/wraptime.cc (InitTM): Check HAVE_SYS_TIME_H
before using struct tm to obtain the size.
gcc/testsuite/ChangeLog:
PR modula2/115276
* gm2/isolib/run/pass/testinittm.mod: New test.
Andrew Pinski [Mon, 27 May 2024 00:38:37 +0000 (17:38 -0700)]
match: Add support for `a ^ CST` to bitwise_inverted_equal_p [PR115224]
While looking into something else, I noticed that `a ^ CST` needed to be
special casing to bitwise_inverted_equal_p as it would simplify to `a ^ ~CST`
for the bitwise not.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Andrew Pinski [Sun, 26 May 2024 06:29:48 +0000 (23:29 -0700)]
Match: Add maybe_bit_not instead of plain matching
While working on adding matching of negative expressions of `a - b`,
I noticed that we started to have "duplicated" patterns due to not having
a way to match maybe negative expressions. So I went back to what I did for
bit_not and decided to improve the situtation there so for some patterns
where we had 2 operands of an expression where one could have been a bit_not,
add back maybe_bit_not.
This does not add maybe_bit_not in every place were bitwise_inverted_equal_p
is used, just the ones were 2 operands of an expression could be swapped.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd (bit_not_with_nop): Unconditionalize.
(maybe_cmp): Likewise.
(maybe_bit_not): New match pattern.
(`~X & X`): Use maybe_bit_not and add `:c` back.
(`~x ^ x`/`~x | x`): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
aarch64: Split aarch64_combinev16qi before RA [PR115258]
Two-vector TBL instructions are fed by an aarch64_combinev16qi, whose
purpose is to put the two input data vectors into consecutive registers.
This aarch64_combinev16qi was then split after reload into individual
moves (from the first input to the first half of the output, and from
the second input to the second half of the output).
In the worst case, the RA might allocate things so that the destination
of the aarch64_combinev16qi is the second input followed by the first
input. In that case, the split form of aarch64_combinev16qi uses three
eors to swap the registers around.
This PR is about a test where this worst case occurred. And given the
insn description, that allocation doesn't semm unreasonable.
early-ra should (hopefully) mean that we're now better at allocating
subregs of vector registers. The upcoming RA subreg patches should
improve things further. The best fix for the PR therefore seems
to be to split the combination before RA, so that the RA can see
the underlying moves.
Perhaps it even makes sense to do this at expand time, avoiding the need
for aarch64_combinev16qi entirely. That deserves more experimentation
though.
gcc/
PR target/115258
* config/aarch64/aarch64-simd.md (aarch64_combinev16qi): Allow
the split before reload.
* config/aarch64/aarch64.cc (aarch64_split_combinev16qi): Generalize
into a form that handles pseudo registers.
gcc/testsuite/
PR target/115258
* gcc.target/aarch64/pr115258.c: New test.
François Dumont [Thu, 16 May 2024 04:59:50 +0000 (06:59 +0200)]
libstdc++: Use RAII to replace try/catch blocks
Move _Guard into std::vector declaration and use it to guard all calls to
vector _M_allocate.
Doing so the compiler has more visibility on what is done with the pointers
and do not raise anymore the -Wfree-nonheap-object warning.
libstdc++-v3/ChangeLog:
* include/bits/vector.tcc (_Guard): Move all the nested duplicated class...
* include/bits/stl_vector.h (_Guard_alloc): ...here and rename.
(_M_allocate_and_copy): Use latter.
(_M_initialize_dispatch): Small code simplification.
(_M_range_initialize): Likewise and set _M_finish first from the result
of __uninitialize_fill_n_a that can throw.
Feng Xue [Thu, 16 May 2024 03:08:38 +0000 (11:08 +0800)]
vect: Unify bbs in loop_vec_info and bb_vec_info
Both derived classes have their own "bbs" field, which have exactly same
purpose of recording all basic blocks inside the corresponding vect region,
while the fields are composed by different data type, one is normal array,
the other is auto_vec. This difference causes some duplicated code even
handling the same stuff, almost in tree-vect-patterns. One refinement is
lifting this field into the base class "vec_info", and reset its value to
the continuous memory area pointed by two old "bbs" in each constructor
of derived classes.
2024-05-16 Feng Xue <fxue@os.amperecomputing.com>
gcc/
* tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Move
initialization of bbs to explicit construction code. Adjust the
definition of nbbs.
(update_epilogue_loop_vinfo): Update nbbs for epilog vinfo.
* tree-vect-patterns.cc (vect_determine_precisions): Make
loop_vec_info and bb_vec_info share same code.
(vect_pattern_recog): Remove duplicated vect_pattern_recog_1 loop.
* tree-vect-slp.cc (vect_get_and_check_slp_defs): Access to bbs[0]
via base vec_info class.
(_bb_vec_info::_bb_vec_info): Initialize bbs and nbbs using data
fields of input auto_vec<> bbs.
(vect_slp_region): Use access to nbbs to replace original
bbs.length().
(vect_schedule_slp_node): Access to bbs[0] via base vec_info class.
* tree-vectorizer.cc (vec_info::vec_info): Add initialization of
bbs and nbbs.
(vec_info::insert_seq_on_entry): Access to bbs[0] via base vec_info
class.
* tree-vectorizer.h (vec_info): Add new fields bbs and nbbs.
(LOOP_VINFO_NBBS): New macro.
(BB_VINFO_BBS): Rename BB_VINFO_BB to BB_VINFO_BBS.
(BB_VINFO_NBBS): New macro.
(_loop_vec_info): Remove field bbs.
(_bb_vec_info): Rename field bbs.
Jason Merrill [Wed, 14 Feb 2024 22:18:17 +0000 (17:18 -0500)]
c++: pragma target and static init [PR109753]
#pragma target and optimize should also apply to implicitly-generated
functions like static initialization functions and defaulted special member
functions.
The handle_optimize_attribute change is necessary to avoid regressing
g++.dg/opt/pr105306.C; maybe_clone_body creates a cgraph_node for the ~B
alias before handle_optimize_attribute, and the alias never goes through
finalize_function, so we need to adjust semantic_interposition somewhere
else.
PR c++/109753
gcc/c-family/ChangeLog:
* c-attribs.cc (handle_optimize_attribute): Set
cgraph_node::semantic_interposition.
Jeff Law [Wed, 29 May 2024 13:41:55 +0000 (07:41 -0600)]
[to-be-committed] [RISC-V] Use pack to handle repeating constants
This patch utilizes zbkb to improve the code we generate for 64bit constants
when the high half is a duplicate of the low half.
Basically we generate the low half and use a pack instruction with that same
register repeated. ie
pack dest,src,src
That gives us a maximum sequence of 3 instructions and sometimes it will be
just 2 instructions (say if the low 32bits can be constructed with a single
addi or lui).
As with shadd, I'm abusing an RTL opcode. This time it's CONCAT. It's
reasonably close to what we're doing. Obviously it's just how we identify the
desire to generate a pack in the array of opcodes. We don't actually emit a
CONCAT.
Note that we don't care about the potential sign extension from bit 31. pack
will only look at bits 0..31 of each input (for rv64). So we go ahead and sign
extend before synthesizing the low part as that allows us to handle more cases
trivially.
I had my testsuite generator chew on random cases of a repeating constant
without any surprises. I don't see much point in including all those in the
testcase (after all there's 2**32 of them). I've got a set of 10 I'm
including. Nothing particularly interesting in them.
An enterprising developer that needs this improved without zbkb could probably
do so with a bit of work. First increase the cost by 1 unit. Second avoid
cases where bit 31 is set and restrict it to cases when we can still create
pseudos. On the codegen side, when encountering the CONCAT, generate the
appropriate shift of "X" into a temporary register, then IOR the temporary with
"X" into the new destination.
Anyway, I've tested this in my tester (though it doesn't turn on zbkb, yet).
I'll let the CI system chew on it overnight, but like mine, I don't think it
lights up zbkb. So it's unlikely to spit out anything interesting.
gcc/
* config/riscv/crypto.md (riscv_xpack_<X:mode>_<HX:mode>_2): Remove '*'
allow it to be used via the gen_* interface.
* config/riscv/riscv.cc (riscv_build_integer): Identify when Zbkb
can be used to profitably synthesize repeating constants.
(riscv_move_integer): Codegen changes to generate those Zbkb sequences.
Jason Merrill [Thu, 16 May 2024 20:09:12 +0000 (16:09 -0400)]
c++: add module extensions
There is a trend in the broader C++ community to use a different extension
for module interface units, even though (in GCC) they are compiled in the
same way as other source files. Let's recognize these extensions as C++.
.ixx is the MSVC standard, while the .c*m are supported by Clang. libc++
standard headers use .cppm, as their other source files use .cpp.
Perhaps libstdc++ might use .ccm for parallel consistency?
One issue with .c++m is that libcpp/mkdeps.cc has been using it for the
phony dependencies to express module dependencies, so I'm changing mkdeps to
something less likely to be an actual file, ".c++-module".
gcc/cp/ChangeLog:
* lang-specs.h: Add module interface extensions.
gcc/ChangeLog:
* doc/invoke.texi: Update module extension docs.
libcpp/ChangeLog:
* mkdeps.cc (make_write): Change .c++m to .c++-module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/dep-1_a.C
* g++.dg/modules/dep-1_b.C
* g++.dg/modules/dep-2.C: Change .c++m to .c++-module.
Tobias Burnus [Wed, 29 May 2024 13:29:06 +0000 (15:29 +0200)]
libgomp: Enable USM for AMD APUs and MI200 devices
If HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT is true,
all GPUs on the system support unified shared memory. That's
the case for APUs and MI200 devices when XNACK is enabled.
XNACK can be enabled by setting HSA_XNACK=1 as env var for
supported devices; otherwise, if disable, USM code will
use host fallback.
Tobias Burnus [Wed, 29 May 2024 13:14:38 +0000 (15:14 +0200)]
libgomp: Enable USM for some nvptx devices
A few high-end nvptx devices support the attribute
CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS; for those, unified shared
memory is supported in hardware. This patch enables support for those -
if all installed nvptx devices have this feature (as the capabilities
are per device type).
This exposes a bug in gomp_copy_back_icvs as it did before use
omp_get_mapped_ptr to find mapped variables, but that returns
the unchanged pointer in cased of shared memory. But in this case,
we have a few actually mapped pointers - like the ICV variables.
Additionally, there was a mismatch with regards to '-1' for the
device number as gomp_copy_back_icvs and omp_get_mapped_ptr count
differently. Hence, do the lookup manually.
* libgomp.texi (nvptx): Update USM description.
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_get_num_devices):
Claim support when requesting USM and all devices support
CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS.
* target.c (gomp_copy_back_icvs): Fix device ptr lookup.
(gomp_target_init): Set GOMP_OFFLOAD_CAP_SHARED_MEM is the
devices supports USM.
Oskari Pirhonen [Wed, 28 Feb 2024 01:13:30 +0000 (19:13 -0600)]
c-family: add hints for strerror
Add proper hints for implicit declaration of strerror.
The results could be confusing depending on the other included headers.
These example messages are from compiling a trivial program to print the
string for an errno value. It only includes stdio.h (cstdio for C++).
Before:
$ /tmp/gcc-master/bin/gcc test.c -o test_c
test.c: In function ‘main’:
test.c:4:20: warning: implicit declaration of function ‘strerror’; did you mean ‘perror’? [-Wimplicit-function-declaration]
4 | printf("%s\n", strerror(0));
| ^~~~~~~~
| perror
$ /tmp/gcc-master/bin/g++ test.cpp -o test_cpp
test.cpp: In function ‘int main()’:
test.cpp:4:20: error: ‘strerror’ was not declared in this scope; did you mean ‘stderr’?
4 | printf("%s\n", strerror(0));
| ^~~~~~~~
| stderr
After:
$ /tmp/gcc-known-headers/bin/gcc test.c -o test_c
test.c: In function ‘main’:
test.c:4:20: warning: implicit declaration of function ‘strerror’ [-Wimplicit-function-declaration]
4 | printf("%s\n", strerror(0));
| ^~~~~~~~
test.c:2:1: note: ‘strerror’ is defined in header ‘<string.h>’; this is probably fixable by adding ‘#include <string.h>’
1 | #include <stdio.h>
+++ |+#include <string.h>
2 |
$ /tmp/gcc-known-headers/bin/g++ test.cpp -o test_cpp
test.cpp: In function ‘int main()’:
test.cpp:4:20: error: ‘strerror’ was not declared in this scope
4 | printf("%s\n", strerror(0));
| ^~~~~~~~
test.cpp:2:1: note: ‘strerror’ is defined in header ‘<cstring>’; this is probably fixable by adding ‘#include <cstring>’
1 | #include <cstdio>
+++ |+#include <cstring>
2 |
Richard Biener [Mon, 27 May 2024 14:04:35 +0000 (16:04 +0200)]
tree-optimization/115252 - enhance peeling for gaps avoidance
Code generation for contiguous load vectorization can already deal
with generalized avoidance of loading from a gap. The following
extends detection of peeling for gaps requirement with that,
gets rid of the old special casing of a half load and makes sure
when we do access the gap we have peeling for gaps enabled.
PR tree-optimization/115252
* tree-vect-stmts.cc (get_group_load_store_type): Enhance
detecting the number of cases where we can avoid accessing a gap
during code generation.
(vectorizable_load): Remove old half-vector peeling for gap
avoidance which is now redundant. Add gap-aligned case where
it's OK to access the gap. Add assert that we have peeling for
gaps enabled when we access a gap.
Richard Biener [Wed, 29 May 2024 08:41:51 +0000 (10:41 +0200)]
tree-optimization/114435 - pcom left around copies confusing SLP
The following arranges for the pre-SLP vectorization scalar cleanup
to be run when predictive commoning was applied to a loop in the
function. This is similar to the complete unroll situation and
facilitating SLP vectorization. Avoiding the SSA copies in predictive
commoning itself isn't easy (and predcom also sometimes unrolls,
asking for scalar cleanup).
PR tree-optimization/114435
* tree-predcom.cc (tree_predictive_commoning): Queue
the next scalar cleanup sub-pipeline to be run when we
did something.
Hongyu Wang [Wed, 15 May 2024 03:24:34 +0000 (11:24 +0800)]
i386: Fix ix86_option override after change [PR 113719]
In ix86_override_options_after_change, calls to ix86_default_align
and ix86_recompute_optlev_based_flags will cause mismatched target
opt_set when doing cl_optimization_restore. Move them back to
ix86_option_override_internal to solve the issue.
gcc/ChangeLog:
PR target/113719
* config/i386/i386-options.cc (ix86_override_options_after_change):
Remove call to ix86_default_align and
ix86_recompute_optlev_based_flags.
(ix86_option_override_internal): Call ix86_default_align and
ix86_recompute_optlev_based_flags.
Patrick Palka [Wed, 29 May 2024 08:49:37 +0000 (04:49 -0400)]
c++: canonicity of fn types w/ instantiated eh specs [PR115223]
When propagating structural equality in build_cp_fntype_variant, we
should consider structural equality of the exception-less variant, not
of the given type which might use structural equality only because it
has a (complex) noexcept-spec that we're intending to replace, as in
maybe_instantiate_noexcept which calls build_exception_variant using
the deferred-noexcept function type. Otherwise we might pessimistically
use structural equality for a function type with a simple instantiated
noexcept-spec, leading to a LTO-triggered type verification failure if we
later use that (structural-equality) type as the canonical version of
some other variant.
PR c++/115223
gcc/cp/ChangeLog:
* tree.cc (build_cp_fntype_variant): Propagate structural
equality of the exception-less variant.
Rainer Orth [Wed, 29 May 2024 08:08:07 +0000 (10:08 +0200)]
libstdc++: Build libbacktrace and 19_diagnostics/stacktrace with -funwind-tables [PR111641]
Several of the 19_diagnostics/stacktrace tests FAIL on Solaris/SPARC (32
and 64-bit), Solaris/x86 (32-bit only), and several other targets:
FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test
As it turns out, both the copy of libbacktrace in libstdc++ and the
testcases proper need to compiled with -funwind-tables, as is done for
libbacktrace itself.
This isn't an issue on Linux/x86_64 and Solaris/amd64 since 64-bit x86
always defaults to -funwind-tables. 32-bit x86 does, too, when
-fomit-frame-pointer is enabled as on Linux/i686, but unlike
Solaris/i386.
So this patch always enables the option both for the libbacktrace copy
and the testcases.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.
PR libstdc++/115247
* include/experimental/bits/simd.h (__as_vector): Don't use
vector_size(8) on __i386__.
(__vec_shuffle): Never return MMX vectors, widen to 16 bytes
instead.
(concat): Fix padding calculation to pick up widening logic from
__as_vector.
liuhongt [Wed, 29 May 2024 03:14:26 +0000 (11:14 +0800)]
Align tight&hot loop without considering max skipping bytes.
When hot loop is small enough to fix into one cacheline, we should align
the loop with ceil_log2 (loop_size) without considering maximum
skipp bytes. It will help code prefetch.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_avoid_jump_mispredicts): Change
gen_pad to gen_max_skip_align.
(ix86_align_loops): New function.
(ix86_reorg): Call ix86_align_loops.
* config/i386/i386.md (pad): Rename to ..
(max_skip_align): .. this, and accept 2 operands for align and
skip.
Haochen Jiang [Wed, 29 May 2024 03:13:55 +0000 (11:13 +0800)]
Adjust generic loop alignment from 16:11:8 to 16 for Intel processors
Previously, we use 16:11:8 in generic tune for Intel processors, which
lead to cross cache line issue and result in some random performance
penalty in benchmarks with small loops commit to commit.
After changing to always aligning to 16 bytes, it will somehow solve
the issue.
gcc/ChangeLog:
* config/i386/x86-tune-costs.h (generic_cost): Change from
16:11:8 to 16.
Kewen Lin [Wed, 29 May 2024 02:41:12 +0000 (21:41 -0500)]
testsuite, rs6000: Replace powerpc_vsx_ok with powerpc_vsx [PR114842]
As noted in PR114842, most of the test cases which require
effective target check powerpc_vsx_ok actually care about
if VSX feature is enabled, and they should adopt effective
target powerpc_vsx instead. Otherwise, when users specifying
extra -mno-vsx like in RUNTESTFLAGS, powerpc_vsx_ok returns
true but the test is tested without VSX and the test case
would fail. With the commit teaching powerpc_vsx consider
current_compiler_flags, dg-{additional,}-options can be taken
into account when evaluating powerpc_vsx, so this patch also
moves dg-{additional,}-options lines before lines with
dg-require-effective-target to make it effective.
Andrew MacLeod [Wed, 22 May 2024 23:51:16 +0000 (19:51 -0400)]
Gori_on_edge tweaks.
FAST_VRP uses a non-ranger gori_on_edge routine which allows an optional
outgoing_edge_range object if one wanted to use switches. This is now
integrated with the gori () method of a range_query, and is no longer
needed.
* gimple-range-gori.cc (gori_on_edge): Always use static ranges
from the specified range_query.
* gimple-range-gori.h (gori_on_edge): Change prototype.
* gimple-range.cc (dom_ranger::maybe_push_edge): Change arguments
to call.
Kewen Lin [Wed, 29 May 2024 02:13:40 +0000 (21:13 -0500)]
rs6000: Don't clobber return value when eh_return called [PR114846]
As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value. Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one new define_insn_and_split eh_return_internal which
directly calls rs6000_emit_epilogue with epilogue_type
EPILOGUE_TYPE_EH_RETURN instead of the previous treating
normal return with crtl->calls_eh_return specially.
PR target/114846
gcc/ChangeLog:
* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As
EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly
now, adjust the relevant handlings on it.
* config/rs6000/rs6000.md (eh_return expander): Append by calling
gen_eh_return_internal and emit_barrier.
(eh_return_internal): New define_insn_and_split, call function
rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN.
liuhongt [Mon, 19 Feb 2024 05:57:24 +0000 (13:57 +0800)]
Reduce cost of MEM (A + imm).
For MEM, rtx_cost iterates each subrtx, and adds up the costs,
so for MEM (reg) and MEM (reg + 4), the former costs 5,
the latter costs 9, it is not accurate for x86. Ideally
address_cost should be used, but it reduce cost too much.
So current solution is make constant disp as cheap as possible.
gcc/ChangeLog:
PR target/67325
* config/i386/i386.cc (ix86_rtx_costs): Reduce cost of MEM (A
+ imm) to "cost of MEM (A)" + 1.
Andrew MacLeod [Wed, 22 May 2024 23:27:01 +0000 (19:27 -0400)]
More tweaks from gimple_outgoing_range changes.
the dom_ranger used for fast vrp no longer needs a local
gimple_outgoing_range object as it is now always available from the
range_query parent class.
The builtin_unreachable code for adjusting globals and removing the
builtin calls during the final VRP pass can now function with just
a range_query object rather than a specific ranger. This adjusts it to
use the extra methods in the range_query API.
This will now allow removal of builtin_unreachable calls even if there is no
active ranger with dependency info available.
* gimple-range.cc (dom_ranger::dom_ranger): Do not initialize m_out.
(dom_ranger::maybe_push_edge): Use gori () rather than m_out.
* gimple-range.h (dom_ranger::m_out): Remove.
* tree-vrp.cc (remove_unreachable::remove_unreachable): Use a
range-query ranther than a gimple_ranger.
(remove_unreachable::remove): New.
(remove_unreachable::m_ranger): Change to a range_query.
(remove_unreachable::handle_early): If there is no dependency
information, do nothing.
(remove_unreachable::remove_and_update_globals): Do not update
globals if there is no dependecy info to use.
- We always have a target_hash_table and bb_ticks because
init_resource_info is always called. These conditionals are
an ancient artifact: it's been quite a while since
resource.cc was used elsewhere than exclusively from reorg.cc
- In mark_target_live_regs, get rid of a now-redundant "if
(tinfo != NULL)" conditional and replace an "if (bb)" with a
gcc_assert.
A "git diff -wb" (ignore whitespace diff) is better at
showing the actual changes.
* resource.cc (free_resource_info, clear_hashed_info_for_insn): Don't
check for non-null target_hash_table and bb_ticks.
(mark_target_live_regs): Ditto. Replace check for non-NULL result from
BLOCK_FOR_INSN with a call to gcc_assert. Fold code conditioned on
tinfo != NULL.
resource.cc (mark_target_live_regs): Remove check for bb not found
No functional change.
A "git diff -wb" (ignore whitespace diff) shows that this
commit just removes a "if (b != -1)" after a "gcc_assert (b
!= -1)" and also removes the subsequent "else" clause.
* resource.cc (mark_target_live_regs): Remove redundant check for b
being -1, after gcc_assert.
resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN
...and call compute_bb_for_insn in init_resource_info and
free_bb_for_insn in free_resource_info.
I put a gcc_unreachable in that else-clause for a failing
find_basic_block in mark_target_live_regs after the comment that says:
/* We didn't find the start of a basic block. Assume everything
in use. This should happen only extremely rarely. */
SET_HARD_REG_SET (res->regs);
and found that it fails not extremely rarely but extremely early in
the build (compiling libgcc).
That kind of pessimization leads to suboptimal delay-slot-filling.
Instead, do like many machine_dependent_reorg passes and call
compute_bb_for_insn as part of resource.cc initialization.
After this patch, there's a whole "if (b != -1)" conditional that's
dominated by a gcc_assert (b != -1). I separated that, as it's a NFC
whitespace patch that hampers patch readability.
Altogether this improved coremark performance for CRIS at -O2
-march=v10 by 0.36%.
* resource.cc: Include cfgrtl.h. Use BLOCK_FOR_INSN (insn)->index
instead of calling find_basic_block (insn). Assert for not -1.
(find_basic_block): Remove function.
(init_resource_info): Call compute_bb_for_insn.
(free_resource_info): Call free_bb_for_insn.
resource.cc (mark_target_live_regs): Don't look past target insn, PR115182
The PR115182 regression is that a delay-slot for a conditional branch,
is no longer filled with an insn that has been "sunk" because of r15-518-g99b1daae18c095, for cris-elf w. -O2 -march=v10.
There are still sufficient "nearby" dependency-less insns that the
delay-slot shouldn't be empty. In particular there's one candidate in
the loop, right after an off-ramp branch, off the loop: a move from
$r9 to $r3.
beq .L2
nop
move.d $r9,$r3
But, the resource.cc data-flow-analysis incorrectly says it collides
with registers "live" at that .L2 off-ramp. The off-ramp insns
(inlined from simple_rand) look like this (left-to-right direction):
.L2:
move.d $r12,[_seed.0]
move.d $r13,[_seed.0+4]
ret
movem [$sp+],$r8
So, a store of a long long to _seed, a return instruction and a
restoring multi-register-load of r0..r8 (all callee-saved registers)
in the delay-slot of the return insn. The return-value is kept in
$r10,$r11 so in total $r10..$r13 live plus the stack-pointer and
return-address registers. But, mark_target_live_regs says that
$r0..$r8 are also live because it *includes the registers live for the
return instruction*! While they "come alive" after the movem, they
certainly aren't live at the "off-ramp" .L2 label.
The problem is in mark_target_live_regs: it consults a hash-table
indexed by insn uid, where it tracks the currently live registers with
a "generation" count to handle when it moves around insn, filling
delay-slots. As a fall-back, it starts with registers live at the
start of each basic block, calculated by the comparatively modern df
machinery (except that it can fail finding out which basic block an
insn belongs to, at which times it includes all registers film at 11),
and tracks the semantics of insns up to each insn.
You'd think that's all that should be done, but then for some reason
it *also* looks at insns *after the target insn* up to a few branches,
and includes that in the set of live registers! This is the code in
mark_target_live_regs that starts with the call to
find_dead_or_set_registers. I couldn't make sense of it, so I looked
at its history, and I think I found the cause; it's a thinko or
possibly two thinkos. The original implementation, gcc-git-described
as r0-97-g9c7e297806a27f, later moved from reorg.c to resource.c in r0-20470-gca545bb569b756.
I believe the "extra" lookup was intended to counter flaws in the
reorg.c/resource.c register liveness analysis; to inspect insns along
the execution paths to exclude registers that, when looking at
subsequent insns, weren't live. That guess is backed by a sentence in
the updated (i.e. deleted) part of the function head comment for
mark_target_live_regs: "Next, scan forward from TARGET looking for
things set or clobbered before they are used. These are not live."
To me that sounds like flawed register-liveness data.
An epilogue expanded as RTX (i.e. not just assembly code emitted as
text) is introduced in basepoints/gcc-0-1334-gbdac5f5848fb, so before
that time, nobody would notice that saved registers were included as
live registers in delay-slots in "next-to-last" basic blocks.
Then in r0-24783-g96e9c98d59cc40, the intersection ("and") was changed
to a union ("or"), i.e. it added to the set of live registers instead
of thinning it out. In the gcc-patches archives, I see the patch
submission doesn't offer a C test-case and only has RTX snippets
(apparently for SPARC). The message does admit that the change goes
"against what the comments in the code say":
https://gcc.gnu.org/pipermail/gcc-patches/1999-November/021836.html
It looks like this was related to a bug with register liveness info
messed up when moving a "delay-slotted" insn from one slot to another.
But, I can't help but thinking it's just papering over a register
liveness bug elsewhere.
I think, with a reliable "DF_LR_IN", the whole thing *after* tracking
from start-of-bb up to the target insn should be removed; thus.
This patch also removes the now-unused find_dead_or_set_registers
function.
At r15-518, it fixes the issue for CRIS and improves coremark scores
at -O2 -march=v10 a tiny bit (about 0.05%).
PR rtl-optimization/115182
* resource.cc (mark_target_live_regs): Don't look for
unconditional branches after the target to improve on the
register liveness.
(find_dead_or_set_registers): Remove unused function.
Uros Bizjak [Tue, 28 May 2024 18:25:14 +0000 (20:25 +0200)]
i386: Improve access to _Atomic DImode location via XMM regs for SSE4.1 x86_32 targets
Use MOVD/PEXTRD and MOVD/PINSRD insn sequences to move DImode value
between XMM and GPR register sets for SSE4.1 x86_32 targets in order
to avoid spilling the value to stack.
to:
movd %eax, %xmm0
pinsrd $1, %edx, %xmm0
movq %xmm0, b
gcc/ChangeLog:
* config/i386/sync.md (atomic_loaddi_fpu): Use movd/pextrd
to move DImode value from XMM to GPR for TARGET_SSE4_1.
(atomic_storedi_fpu): Use movd/pinsrd to move DImode value
from GPR to XMM for TARGET_SSE4_1.
David Malcolm [Tue, 28 May 2024 19:55:28 +0000 (15:55 -0400)]
diagnostics: consolidate global state in diagnostic-color.cc
Simplify the table of default colors, avoiding the need to manually
add the strlen of each entry.
Consolidate the global state in diagnostic-color.cc into a
g_color_dict, adding selftests for the new class diagnostic_color_dict.
No functional change intended.
gcc/ChangeLog:
* diagnostic-color.cc: Define INCLUDE_VECTOR.
Include "label-text.h" and "selftest.h".
(struct color_cap): Replace with...
(struct color_default): ...this, adding "m_" prefixes to fields
and dropping "name_len" and "free_val" field.
(color_dict): Convert to...
(gcc_color_defaults): ...this, making const, dropping the trailing
strlen and "false" from each entry.
(class diagnostic_color_dict): New.
(g_color_dict): New.
(colorize_start): Reimplement in terms of g_color_dict.
(diagnostic_color_dict::get_entry_by_name): New, based on
colorize_start.
(diagnostic_color_dict::get_start_by_name): Likewise.
(diagnostic_color_dict::diagnostic_color_dict): New.
(parse_gcc_colors): Reimplement, moving body...
(diagnostic_color_dict::parse_envvar_value): ...here.
(colorize_init): Lazily create g_color_dict.
(selftest::test_empty_color_dict): New.
(selftest::test_default_color_dict): New.
(selftest::test_color_dict_envvar_parsing): New.
(selftest::diagnostic_color_cc_tests): New.
* selftest-run-tests.cc (selftest::run_tests): Call
selftest::diagnostic_color_cc_tests.
* selftest.h (selftest::diagnostic_color_cc_tests): New decl.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Marek Polacek [Thu, 23 May 2024 19:49:42 +0000 (15:49 -0400)]
c++: extend -Wself-move for mem-init-list [PR109396]
We already warn for:
x = std::move (x);
which triggers:
warning: moving 'x' of type 'int' to itself [-Wself-move]
but bug 109396 reports that this doesn't work for a member-initializer-list:
X() : x(std::move (x))
so this patch amends that.
PR c++/109396
gcc/cp/ChangeLog:
* cp-tree.h (maybe_warn_self_move): Declare.
* init.cc (perform_member_init): Call maybe_warn_self_move.
* typeck.cc (maybe_warn_self_move): No longer static. Change the
return type to bool. Also warn when called from
a member-initializer-list. Drop the inform call.
Andrew MacLeod [Mon, 27 May 2024 15:00:57 +0000 (11:00 -0400)]
Do not invoke SCEV if it will use a different range query.
SCEV always uses the current range_query object.
Ranger's cache uses a global value_query when propagating cache values to
avoid re-invoking ranger during simple vavhe propagations.
when folding a PHI value, SCEV can be invoked, and since it alwys uses
the current range_query object, when ranger is active this causes the
undesired re-invoking of ranger during cache propagation.
This patch checks to see if the fold_using_range specified range_query
object is the same as the one SCEV uses, and does not invoke SCEV if
they do not match.
PR tree-optimization/115221
gcc/
* gimple-range-fold.cc (range_of_ssa_name_with_loop_info): Do
not invoke SCEV is range_query's do not match.
gcc/testsuite/
* gcc.dg/pr115221.c: New.
Marek Polacek [Wed, 22 May 2024 20:28:02 +0000 (16:28 -0400)]
c++: mark TARGET_EXPRs for function arguments eliding [PR114707]
Coming back to our discussion in
<https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649426.html>:
TARGET_EXPRs that initialize a function argument are not marked
TARGET_EXPR_ELIDING_P even though gimplify_arg drops such TARGET_EXPRs
on the floor. To work around it, I added a pset to
replace_placeholders_for_class_temp_r, but it would be best to just rely
on TARGET_EXPR_ELIDING_P.
PR c++/114707
gcc/cp/ChangeLog:
* call.cc (convert_for_arg_passing): Call set_target_expr_eliding.
* typeck2.cc (replace_placeholders_for_class_temp_r): Don't use pset.
(digest_nsdmi_init): Call cp_walk_tree_without_duplicates instead of
cp_walk_tree.
David Malcolm [Tue, 28 May 2024 17:04:25 +0000 (13:04 -0400)]
Fix bootstrap on AIX by adding c-family/c-type-mismatch.cc [PR115167]
PR bootstrap/115167 reports a bootstrap failure on AIX triggered by r15-636-g770657d02c986c whilst building f951 in stage 2, due to
the linker not being able to find symbols for:
vtable for range_label_for_type_mismatch
range_label_for_type_mismatch::get_text(unsigned int) const
The only users of the class range_label_for_type_mismatch are in the
C/C++ frontends, each of which supply their own implementation of:
i.e. we had a cluster of symbols that was disconnnected from any
users on f951.
The above patch added a new range_label::get_effects vfunc to the
base class. My hunch is that we were getting away with not defining
the symbol for Fortran with AIX's linker before (since none of the
users are used), but adding the get_effects vfunc has somehow broken
things (possibly because there's an empty implementation in the base
class in the *header*).
The following patch moves all of the code in
gcc/gcc-rich-location.[cc,h,o} defining and using
range_label_for_type_mismatch to a new
gcc/c-family/c-type-mismatch.{cc,h,o}, to help the linker ignore this
cluster of symbols when it's disconnected from users.
I was able to reproduce the failure without the patch, and then
successfully bootstrap with this patch on powerpc-ibm-aix7.3.1.0
(cfarm119).
gcc/c-family/ChangeLog:
PR bootstrap/115167
* c-format.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* c-type-mismatch.cc: New file, taking material from
gcc-rich-location.cc.
* c-type-mismatch.h: New file, taking material from
gcc-rich-location.h.
* c-warn.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
gcc/c/ChangeLog:
PR bootstrap/115167
* c-objc-common.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* c-typeck.cc: Likewise.
gcc/cp/ChangeLog:
PR bootstrap/115167
PR bootstrap/115167
* call.cc: Replace include of "gcc-rich-location.h" with
"c-family/c-type-mismatch.h".
* error.cc: Likewise.
* typeck.cc: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Lyut Nersisyan [Tue, 28 May 2024 15:17:50 +0000 (09:17 -0600)]
[to-be-committed] [RISC-V] Some basic patterns for zbkb code generation
And here's Lyut's basic Zbkb support. Essentially it's four new patterns for
packh, packw, pack plus a bridge pattern needed for packh.
packw is a bit ugly as we need to match a sign extension in an inconvenient
location. We pull it out so that the extension is exposed in a convenient
place for subsequent sign extension elimination.
We need a bridge pattern to get packh. Thankfully the bridge pattern is a
degenerate packh where one operand is x0, so it works as-is without splitting
and provides the bridge to the more general form of packh.
This patch also refines the condition for the constant reassociation patch to
avoid a few more cases than can be handled efficiently with other preexisting
patterns and one bugfix to avoid losing bits, particularly in the xor/ior case.
Lyut did the core work here. I think I did some minor cleanups and the bridge
pattern to work with gcc-15 and beyond.
This is a prerequisite for using zbkb in constant synthesis. It also stands on
its own. I know we've seen it trigger in spec without the constant synthesis
bits.
It's been through our internal CI and my tester. I'll obviously wait for the
upstream CI to finish before taking further action.
gcc/
* config/riscv/crypto.md: Add new combiner patterns to generate
pack, packh, packw instrutions.
* config/riscv/iterators.md (HX): New iterator for half X mode.
* config/riscv/riscv.md (<optab>_shift_reverse<X:mode>): Tighten
cases to avoid. Do not lose bits for XOR/IOR.
gcc/testsuite
* gcc.target/riscv/pack32.c: New test.
* gcc.target/riscv/pack64.c: New test.
* gcc.target/riscv/packh32.c: New test.
* gcc.target/riscv/packh64.c: New test.
* gcc.target/riscv/packw.c: New test.
Co-authored-by: Jeffrey A Law <jlaw@ventanamicro.com>
Feng Xue [Thu, 23 May 2024 07:25:53 +0000 (15:25 +0800)]
vect: Use vect representative statement instead of original in patch recog [PR115060]
Some utility functions (such as vect_look_through_possible_promotion) that are
to find out certain kind of direct or indirect definition SSA for a value, may
return the original one of the SSA, not its pattern representative SSA, even
pattern is involved. For example,
a = (T1) patt_b;
patt_b = (T2) c; // b = ...
patt_c = not-a-cast; // c = ...
Given 'a', the mentioned function will return 'c', instead of 'patt_c'. This
subtlety would make some pattern recog code that is unaware of it mis-use the
original instead of the new pattern statement, which is inconsistent wth
processing logic of the pattern formation pass. This patch corrects the issue
by forcing another utility function (vect_get_internal_def) return the pattern
statement information to caller by default.
2024-05-23 Feng Xue <fxue@os.amperecomputing.com>
gcc/
PR tree-optimization/115060
* tree-vect-patterns.cc (vect_get_internal_def): Return statement for
vectorization.
(vect_widened_op_tree): Call vect_get_internal_def instead of look_def
to get statement information.
(vect_recog_widen_abd_pattern): No need to call vect_stmt_to_vectorize.
The dump scanning is supposed to check that we do not merge two
sligtly different gathers into one SLP node but since we now
SLP the store scanning for "ectorizing stmts using SLP" is no
longer good. Instead the following makes us look for
"stmt 1 .* = .MASK" which would be how the second lane of an SLP
node looks like. We have to handle both .MASK_GATHER_LOAD (for
targets with ifun mask gathers) and .MASK_LOAD (for ones without).
Tested on x86_64-linux with and without native gather and on GCN
where this now avoids a FAIL.
Richard Biener [Mon, 27 May 2024 08:41:02 +0000 (10:41 +0200)]
tree-optimization/115236 - more points-to *ANYTHING = x fixes
The stored-to ANYTHING handling has more holes, uncovered by treating
volatile accesses as ANYTHING. We fail to properly build the
pred and succ graphs, in particular we may not elide direct nodes
from receiving from STOREDANYTHING.
PR tree-optimization/115236
* tree-ssa-structalias.cc (build_pred_graph): Properly
handle *ANYTHING = X.
(build_succ_graph): Likewise. Do not elide direct nodes
from receiving from STOREDANYTHING.
Richard Biener [Tue, 28 May 2024 11:29:30 +0000 (13:29 +0200)]
Avoid pessimistic constraints for asm memory constraints
We process asm memory input/outputs with constraints to ESCAPED
but for this temporarily build an ADDR_EXPR. The issue is that
the used build_fold_addr_expr ends up wrapping the ADDR_EXPR in
a conversion which ends up producing &ANYTHING constraints which
is quite bad. The following uses get_constraint_for_address_of
instead, avoiding the temporary tree and the unhandled conversion.
This avoids a gcc.dg/tree-ssa/restrict-9.c FAIL with the fix
for PR115236.
* tree-ssa-structalias.cc (find_func_aliases): Use
get_constraint_for_address_of to build escape constraints
for asm inputs and outputs.
Richard Biener [Fri, 29 Sep 2023 13:12:54 +0000 (15:12 +0200)]
tree-optimization/115254 - don't account single-lane SLP against discovery limit
The following avoids accounting single-lane SLP to the discovery
limit. As the two testcases show this makes discovery fail,
unfortunately even not the same across targets. The following
should fix two FAILs for GCN as a side-effect.
PR tree-optimization/115254
* tree-vect-slp.cc (vect_build_slp_tree): Only account
multi-lane SLP to limit.
* gcc.dg/vect/slp-cond-2-big-array.c: Expect 4 times SLP.
* gcc.dg/vect/slp-cond-2.c: Likewise.
Andrew Pinski [Mon, 27 May 2024 00:59:21 +0000 (17:59 -0700)]
match: Use uniform_integer_cst_p in bitwise_inverted_equal_p [PR115238]
I noticed while working on the `a ^ CST` patch, that bitwise_inverted_equal_p
would check INTEGER_CST directly and not handle vector csts that are uniform.
This moves over to using uniform_integer_cst_p instead of checking INTEGER_CST
directly.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/115238
gcc/ChangeLog:
* generic-match-head.cc (bitwise_inverted_equal_p): Use
uniform_integer_cst_p instead of checking INTEGER_CST.
* gimple-match-head.cc (gimple_bitwise_inverted_equal_p): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/bitops-9.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Richard Biener [Mon, 27 May 2024 11:50:14 +0000 (13:50 +0200)]
Fix points-to SCC collapsing bug
When points-to analysis finds SCCs it marks the wrong node as being
part of a found cycle. It only wants to mark the node it collapses
to but marked the entry node found rather than the one it collapses
to. This causes fallout in the patch for PR115236 but generally
weakens the points-to solution by collapsing too many nodes. Note
that this fix might slow down points-to solving.
* tree-ssa-structalias.cc (scc_visit): Mark the node we
collapse to as being in a component.
Richard Biener [Mon, 27 May 2024 07:40:19 +0000 (09:40 +0200)]
tree-optimization/115220 - fix store sinking virtual operand constraints
The following makes sure the virtual operand updating when sinking
stores works for the case we ignore paths to kills. The final
sink location might not post-dominate the original stmt location
which would require inserting of a virtual PHI which we do not support.
PR tree-optimization/115220
PR tree-optimization/115226
* tree-ssa-sink.cc (statement_sink_location): When ignoring
paths to kills when sinking stores make sure the final
sink location is still post-dominated by the original one.
Otherwise we'd need to insert a PHI node to merge virtual operands.
* gcc.dg/torture/pr115220.c: New testcase.
* gcc.dg/torture/pr115226.c: New testcase.
Richard Biener [Mon, 27 May 2024 07:13:11 +0000 (09:13 +0200)]
tree-optimization/115232 - demangle failure during -Waccess
For the following testcase we fail to demangle
_ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnernwEm and
_ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnerdlEPv and in turn end
up building NULL references. The following puts in a safeguard for
faile demangling into -Waccess.
PR tree-optimization/115232
* gimple-ssa-warn-access.cc (new_delete_mismatch_p): Handle
failure to demangle gracefully.
Liao Shihua [Fri, 24 May 2024 05:03:57 +0000 (13:03 +0800)]
RISC-V: Fix missing boolean_expression in zmmul extension
Update v1->v2
Add testcase for this patch.
Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause different instructions when
multiplying an integer with a constant. ( https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1482 )
int foo(int *ib) {
*ib = *ib * 33938;
return 0;
}
rv64im:
lw a4,0(a1)
li a5,32768
addiw a5,a5,1170
mulw a5,a5,a4
sw a5,0(a1)
ret
VAX/doc: Fix issues with FP format option documentation
Use the correct names of the D_floating and G_floating data formats as
per the VAX ISA nomenclature[1]. Document the `-md', `-md-float', and
`-mg-float' options.
References:
[1] DEC STD 032-0 "VAX Architecture Standard", Digital Equipment
Corporation, A-DS-EL-00032-00-0 Rev J, December 15, 1989, Section
1.2 "Data Types", pp. 1-7, 1-9
gcc/
* doc/invoke.texi (Option Summary): Add `-md', `-md-float', and
`-mg-float' options. Reorder, matching VAX Options.
(VAX Options): Reword the description of `-mg' option. Add
`-md', `-md-float', and `-mg-float' options.
Lyut Nersisyan [Mon, 27 May 2024 03:24:40 +0000 (21:24 -0600)]
[to-be-committed][RISC-V] Reassociate constants in logical ops
This patch from Lyut will reassociate operands when we have shifted logical
operations. This can simplify a constant that may not be fit in a simm12 into
a form that does fit into a simm12.
The basic work was done by Lyut. I generalized it to handle XOR/OR.
It stands on its own, but also helps the upcoming Zbkb work from Lyut.
This has survived Ventana's CI system as well as my tester. Obviously I'll
wait for a verdict from the Rivos CI system before moving forward.
gcc/
* config/riscv/riscv.md (<optab>_shift_reverse<X:mode>): New pattern.
gcc/testsuite
* gcc.target/riscv/and-shift32.c: New test.
* gcc.target/riscv/and-shift64.c: New test.
Co-authored-by: Jeffrey A Law <jlaw@ventanamicro.com>
Levy Hsu [Tue, 21 May 2024 03:17:21 +0000 (12:47 +0930)]
x86: Fix Logical Shift Issue in expand_vec_perm_psrlw_psllw_por [PR115146]
Replaced arithmetic shifts with logical shifts in expand_vec_perm_psrlw_psllw_por to avoid sign bit extension issues. Also corrected gen_vlshrv8hi3 to gen_lshrv8hi3 and gen_vashlv8hi3 to gen_ashlv8hi3.
Co-authored-by: H.J. Lu <hjl.tools@gmail.com>
gcc/ChangeLog:
PR target/115146
* config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por): Replace arithmatic shift
gen_ashrv4hi3 with logic shift gen_lshrv4hi3.
Replace gen_vlshrv8hi3 with gen_lshrv8hi3 and gen_vashlv8hi3 with gen_ashlv8hi3.
gcc/testsuite/ChangeLog:
PR target/115146
* g++.target/i386/pr107563-a.C: Append '-mno-sse3' to compile option
to avoid test failure on hosts with SSE3 support.
* g++.target/i386/pr107563-b.C: Append '-mno-sse3' to compile option
to avoid test failure on hosts with SSE3 support.
* gcc.target/i386/pr115146.c: New test.
Jeff Law [Sun, 26 May 2024 23:54:51 +0000 (17:54 -0600)]
[to-be-committed] [RISC-V] Try inverting for constant synthesis
So there's another class of constants we're failing to synthesize well.
Specifically those where we can invert our original constant C into C' and C'
takes at least 2 fewer instructions to synthesize than C. In that case we can
initially generate C', then use xori with the constant -1 to flip all the bits
resulting in our target constant.
I've only seen this trigger when the final synthesis is li+srli+xori. The
original synthesis took on various 4 or 5 instruction forms.
Most of the methods we use to improve constant synthesis are in
riscv_build_integer_1. I originally tried to put this code in there. But
that'll end up with infinite recursion due to some other ADDI related code
which wants to flip bits and try synthesis.
So this was put into riscv_build_integer and recurses into riscv_build_integer.
This isn't unprecedented, just a bit different than most of the other synthesis
implementation bits.
This doesn't depend on any extensions. So it should help any rv64 system.
gcc/
* config/riscv/riscv.cc (riscv_build_integer_one): Verify there
are no bits left to set in the constant when generating bseti.
(riscv_built_integer): Synthesize ~value and if it's cheap use it
with a trailing xori with -1.
Jeff Law [Sun, 26 May 2024 16:54:18 +0000 (10:54 -0600)]
[to-be-committed][RISC-V] Generate nearby constant, then adjust to our final desired constant
Next step in constant synthesis work.
For some cases it can be advantageous to generate a constant near our target,
then do a final addi to fully synthesize C.
The idea is that while our target C may require N instructions to synthesize,
C' may only require N-2 (or fewer) instructions. Thus there's budget to adjust
C' into C ending up with a better sequence than if we tried to generate C
directly.
So as an example:
> unsigned long foo_0xfffff7fe7ffff7ff(void) { return 0xfffff7fe7ffff7ffUL; }
But we can do better by first synthesizing 0xfffff7fe7ffff800 which is just 3
instructions. Then we can subtract 1 from the result. That gives us this
sequence:
These cases are relatively easy to find once you know what you're looking for.
I kept the full set found by the testing code yesterday, mostly because some of
them show different patterns for generating C', thus showing generality in the
overall synthesis implementation. While all these tests have 0x7ff in their
low bits. That's just an artifact to the test script. The methodology will
work for a variety of other cases.
gcc/
* config/riscv/riscv.cc (riscv_build_integer_1): Try generating
a nearby simpler constant, then using a final addi to set low
bits properly.
Andrew MacLeod [Sat, 25 May 2024 16:28:52 +0000 (12:28 -0400)]
Delete gori_map during destruction of GORI.
Forgot to free the gori_mpa object when a gori object is freed.
PR tree-optimization/115208
* value-query.cc (range_query::create_gori): Confirm gori_map is NULL.
(range_query::destroy_gori): Free gori_map if one was allocated.
Jeff Law [Sat, 25 May 2024 18:39:05 +0000 (12:39 -0600)]
[committed] [v2] More logical op simplifications in simplify-rtx.cc
This is a revamp of what started as a target specific patch.
Basically xalan (corrected, I originally thought it was perlbench) has a bitset
implementation with a bit of an oddity. Specifically setBit will clear the bit
before it is set:
> if (bitToSet < 32)
> {
> fBits1 &= ~mask;
> fBits1 |= mask;
> }
> else
> {
> fBits2 &= ~mask;
> fBits2 |= mask;
> }
We can clean this up pretty easily in RTL with a small bit of code in
simplify-rtx. While xalan doesn't have other cases, we can synthesize tests
pretty easily and handle them as well.
It turns out we don't actually have to recognize this stuff at the bit level,
just standard logical identities are sufficient. For example
(X | Y) & ~Y -> X & ~Y
Andrew P. might poke at this at the gimple level. The type changes kindof get
in the way in gimple but he's much better at match.pd than I am, so if he wants
to chase it from the gimple side, I'll fully support that.
Bootstrapped and regression tested on x86. Also run through my tester on its
embedded targets.
Pushing to the trunk.
gcc/
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1): Handle
more logical simplifications.
gcc/testsuite/
* g++.target/riscv/redundant-bitmap-1.C: New test.
* g++.target/riscv/redundant-bitmap-2.C: New test.
* g++.target/riscv/redundant-bitmap-3.C: New test.
* g++.target/riscv/redundant-bitmap-4.C: New test.
Nathaniel Shead [Fri, 24 May 2024 15:03:54 +0000 (01:03 +1000)]
c++/modules: Improve diagnostic when redeclaring builtin in module [PR102345]
If a user mistakenly includes a standard library header within the
module purview, they currently get a confusing "declaration conflicts
with builtin" error. This patch updates the message to include "in
module", to help guide the user towards the likely cause.
PR fortran/93635
* symbol.cc (conflict_std): Helper function for reporting attribute
conflicts depending on the Fortran standard version.
(conf_std): Helper macro for checking standard-dependent conflicts.
(gfc_check_conflict): Use it.
Harald Anlauf [Mon, 13 May 2024 20:06:33 +0000 (22:06 +0200)]
Fortran: fix bounds check for assignment, class component [PR86100]
gcc/fortran/ChangeLog:
PR fortran/86100
* trans-array.cc (gfc_conv_ss_startstride): Use abridged_ref_name
to generate a more user-friendly name for bounds-check messages.
* trans-expr.cc (gfc_copy_class_to_class): Fix bounds check for
rank>1 by looping over the dimensions.
gcc/testsuite/ChangeLog:
PR fortran/86100
* gfortran.dg/bounds_check_25.f90: New test.
Eric Botcazou [Fri, 24 May 2024 17:48:18 +0000 (19:48 +0200)]
Small enhancement to implementation of -fdump-ada-spec
This lets it recognize more preprocessing floating constants.
gcc/c-family/
* c-ada-spec.cc (is_cpp_float): New predicate.
(dump_number): Deal with more preprocessing floating constants.
(dump_ada_macros) <CPP_NUMBER>: Use is_cpp_float.
Martin Uecker [Sat, 18 May 2024 12:40:02 +0000 (14:40 +0200)]
c: Fix for some variably modified types not being recognized [PR114831]
We did not evaluate expressions with variably modified types correctly
in typeof and did not produce warnings when jumping over declarations
using typeof. After addressof or array-to-pointer decay we construct
new pointer types that have to be marked variably modified if the pointer
target is variably modified.
2024-05-18 Martin Uecker <uecker@tugraz.at>
PR c/114831
gcc/c/
* c-typeck.cc (array_to_pointer_conversion, build_unary_op):
Propagate flag to pointer target.
gcc/testsuite/
* gcc.dg/pr114831-1.c: New test.
* gcc.dg/pr114831-2.c: New test.
* gcc.dg/gnu23-varmod-1.c: New test.
* gcc.dg/gnu23-varmod-2.c: New test.
Nathaniel Shead [Thu, 23 May 2024 14:08:57 +0000 (00:08 +1000)]
c++/modules: Improve errors for bad module-directives [PR115200]
This fixes an ICE when a module directive is not given at global scope.
Although not explicitly mentioned, it seems implied from [basic.link] p1
and [module.global.frag] that a module-declaration must appear at the
global scope after preprocessing. Apart from this the patch also
slightly improves the errors given when accidentally using a module
control-line in other situations where it is not expected.
PR c++/115200
gcc/cp/ChangeLog:
* parser.cc (cp_parser_error_1): Special-case unexpected module
directives for better diagnostics.
(cp_parser_module_declaration): Check that the module
declaration is at global scope.
(cp_parser_import_declaration): Sync error message with that in
cp_parser_error_1.
gcc/testsuite/ChangeLog:
* g++.dg/modules/mod-decl-1.C: Update error messages.
* g++.dg/modules/mod-decl-6.C: New test.
* g++.dg/modules/mod-decl-7.C: New test.
* g++.dg/modules/mod-decl-8.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Thu, 23 May 2024 12:56:52 +0000 (22:56 +1000)]
c++/modules: Remember that header units have CMIs
This appears to be an oversight in the definition of module_has_cmi_p.
This change will allow us to use the function directly in more places
that need to additional work only if generating a module CMI in the
future, allowing us to do additional work only when we know we need it.
gcc/cp/ChangeLog:
* cp-tree.h (module_has_cmi_p): Also include header units.
(module_maybe_has_cmi_p): Update comment.
* module.cc (set_defining_module): Only need to track
declarations for later exporting if the module may have a CMI.
(set_defining_module_for_partial_spec): Likewise.
* name-lookup.cc (pushdecl): Likewise.
Nathaniel Shead [Thu, 23 May 2024 12:50:58 +0000 (22:50 +1000)]
c++/modules: Fix treatment of unnamed types
In r14-9530 we relaxed "depending on type with no-linkage" errors for
declarations that could actually be accessed from different TUs anyway.
However, this also enabled it for unnamed types, which never work.
In a normal module interface, an unnamed type is TU-local by
[basic.link] p15.2, and so cannot be exposed or the program is
ill-formed. We don't yet implement this checking but we should assume
that we will later; currently supporting this actually causes ICEs when
attempting to create the mangled name in some situations.
For a header unit, by [module.import] p5.3 it is unspecified whether two
TUs importing a header unit providing such a declaration are importing
the same header unit. In this case, we would require name mangling
changes to somehow allow the (anonymous) type exported by such a header
unit to correspond across different TUs in the presence of other
anonymous declarations, so for this patch just assume that this case
would be an ODR violation instead.
gcc/cp/ChangeLog:
* tree.cc (no_linkage_check): Anonymous types can't be accessed
in a different TU.
gcc/testsuite/ChangeLog:
* g++.dg/modules/linkage-1_a.C: Remove anonymous type test.
* g++.dg/modules/linkage-1_b.C: Likewise.
* g++.dg/modules/linkage-1_c.C: Likewise.
* g++.dg/modules/linkage-2.C: Add note about anonymous types.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jeff Law [Fri, 24 May 2024 13:27:00 +0000 (07:27 -0600)]
[to-be-committed,v2,RISC-V] Use bclri in constant synthesis
Testing with Zbs enabled by default showed a minor logic error. After
the loop clearing things with bclri, we can only use the sequence if we
were able to clear all the necessary bits. If any bits are still on,
then the bclr sequence turned out to not be profitable.
--
So this is conceptually similar to how we handled direct generation of
bseti for constant synthesis, but this time for bclr.
In the bclr case, we already have an expander for AND. So we just
needed to adjust the predicate to accept another class of constant
operands (those with a single bit clear).
With that in place constant synthesis is adjusted so that it counts the
number of bits clear in the high 33 bits of a 64bit word. If that
number is small relative to the current best cost, then we try to
generate the constant with a lui based sequence for the low half which
implicitly sets the upper 32 bits as well. Then we bclri one or more of
those upper 33 bits.
So as an example, this code goes from 4 instructions down to 3:
> unsigned long foo_0xfffffffbfffff7ff(void) { return
0xfffffffbfffff7ffUL; }
Note the use of 33 bits above. That's meant to capture cases like this:
> unsigned long foo_0xfffdffff7ffff7ff(void) { return
0xfffdffff7ffff7ffUL; }
We can use lui+addi+bclri+bclri to synthesize that in 4 instructions
instead of 5.
I'm including a handful of cases covering the two basic ideas above that
were found by the testing code.
And, no, we're not done yet. I see at least one more notable idiom
missing before exploring zbkb's potential to improve things.
Tested in my tester and waiting on Rivos CI system before moving forward.
gcc/
* config/riscv/predicates.md (arith_operand_or_mode_mask): Renamed to..
(arith_or_mode_mask_or_zbs_operand): New predicate.
* config/riscv/riscv.md (and<mode>3): Update predicate for operand 2.
* config/riscv/riscv.cc (riscv_build_integer_1): Use bclri to clear
bits, particularly bits 31..63 when profitable to do so.
create_intersect_range_checks checks whether two access ranges
a and b are alias-free using something equivalent to:
end_a <= start_b || end_b <= start_a
It has two ways of doing this: a "vanilla" way that calculates
the exact exclusive end pointers, and another way that uses the
last inclusive aligned pointers (and changes the comparisons
accordingly). The comment for the latter is:
/* Calculate the minimum alignment shared by all four pointers,
then arrange for this alignment to be subtracted from the
exclusive maximum values to get inclusive maximum values.
This "- min_align" is cumulative with a "+ access_size"
in the calculation of the maximum values. In the best
(and common) case, the two cancel each other out, leaving
us with an inclusive bound based only on seg_len. In the
worst case we're simply adding a smaller number than before.
The problem is that the associated code implicitly assumed that the
access size was a multiple of the pointer alignment, and so the
alignment could be carried over to the exclusive end pointer.
The testcase started failing after g:9fa5b473b5b8e289b6542
because that commit improved the alignment information for
the accesses.
gcc/
PR tree-optimization/115192
* tree-data-ref.cc (create_intersect_range_checks): Take the
alignment of the access sizes into account.
gcc/testsuite/
PR tree-optimization/115192
* gcc.dg/vect/pr115192.c: New test.
Manolis Tsamis [Wed, 1 Nov 2023 11:27:28 +0000 (12:27 +0100)]
MATCH: Look through VIEW_CONVERT when folding VEC_PERM_EXPRs.
The match.pd patterns to merge two vector permutes into one fail when a
potentially no-op view convert expressions is between the two permutes.
This change lifts this restriction.
gcc/ChangeLog:
* match.pd: Allow no-op view_convert between permutes.
projects / thirdparty / gcc.git / log
