| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Evalaute ssa-names when range_of_expr is called with no context statement
by calling range_of_stmt to get an initial value.
* gimple-range.cc (gimple_ranger::range_of_expr): Call range_of_stmt
when there is no context stmt.
|
|
Do not pre-evaluate PHIs in the cache, and allow fill_block_cache to
be re-entrant. This allows SCEV to call into ranger with a context
and not produce cycles or loops.
* gimple-range-cache.cc (ranger_cache::get_global_range): Do not
pre-evaluate PHI nodes from the cache.
(ranger_cache::fill_block_cache): Make re-entrant.
|
|
Now that legacy EVRP has been removed, we can remove the wrapper which
prevented us from using global names before inlining except under
some specific conditions. See discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
* value-query.cc (get_range_global): Rename to gimple_range_global.
(gimple_range_global): Remove wrapper function.
(global_range_query::range_of_expr): Call gimple_range_global.
|
|
The problem here is the quote mark is for English's
possessiveness rather than a quote but the error message
format detection is too simple so it warns which causes
-Werror to fail.
Committed as obvious after a quick build.
gcc/ChangeLog:
* tree-cfg.cc (verify_gimple_assign): Remove quote
mark to shut up the warning.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
While moving value replacement part of PHIOPT over
to use match-and-simplify, I ran into the case where
we would have an undef use that was conditional become
unconditional. This prevents that. I can't remember at this
point what the testcase was though.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (value_replacement): Reject undef variables
so they don't become unconditional used.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
This adds a few early outs to value_replacement that I noticed
while rewriting this to use match-and-simplify but could be committed
seperately.
* virtual operands won't change so return early for them
* special case `A ? B : B` as that is already just `B`
Also moves the check for NE/EQ earlier as calculating empty_or_with_defined_p
is an IR walk for a BB and that might be big.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (value_replacement): Move check for
NE/EQ earlier.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
I noticed that single_non_singleton_phi_for_edges could
return a phi whos entry are all the same for the edge.
This happens only if there was a single phis in the first place.
Also gimple_seq_singleton_p walks the sequence to see if it the one
element in the sequence so there is removing that check actually
reduces the number of pointer walks needed.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (single_non_singleton_phi_for_edges):
Remove the special case of gimple_seq_singleton_p.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
When cfgexpand was changed to support expanding from tuple gimple
(r0-95521-g28ed065ef9f345), the code was added to support
doing nontemporal stores with LHS of a SSA_NAME but that will
never be a nontemporal store.
This patch removes that and asserts that expanding with a LHS
of a SSA_NAME is not a nontemporal store.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR middle-end/112976
* cfgexpand.cc (expand_gimple_stmt_1): Remove
support for expanding nontemporal "moves" with
ssa names on the LHS.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
Currently the middle-end only knows how to support temporal stores
(the undocumented storent optab) so let's verify that the only time
we set nontemporal_move on an assign is if the the lhs is not a
gimple reg.
Bootstrapped and tested on x86_64-linux-gnu no regressions.
gcc/ChangeLog:
PR middle-end/112976
* tree-cfg.cc (verify_gimple_assign): Verify that
nontmporal moves are stores.
* gimple.h (struct gimple): Note that only
nontemporal stores are supported.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg336483.html
This patch is primarily meant to improve the code we generate for FP rounding
such as ceil/floor. It also addresses some unnecessary sign extensions in the
same areas.
RISC-V's FP conversions have a bit of undesirable behavior that make them
non-suitable as-is for ceil/floor and other related functions. These
deficiencies are addressed in the Zfa extension, but there's no reason not to
pick up a nice improvement when we can.
Basically we can still use the basic FP conversions for floor/ceil and friends
when we don't care about inexact exceptions by checking for the special cases
first, then emitting the conversion when the special cases don't apply. That's
still much faster than calling into glibc.
The redundant sign extensions are eliminated using the same trick Jivan added
last year, just in a few more places ;-)
This eliminates roughly 10% of the dynamic instruction count for imagick. But
more importantly it's about a 17% performance improvement for that workload
within spec.
This has been bootstrapped as well as regression tested in a cross environment.
It's also successfully built & run specint/specfp correctly.
Pushing to the trunk and the coordination branch momentarily.
gcc/
* config/riscv/iterators.md (fix_ops, fix_uns): New iterators.
(RINT, rint_pattern, rint_rm): Remove unused iterators.
* config/riscv/riscv-protos.h (get_fp_rounding_coefficient): Prototype.
* config/riscv/riscv-v.cc (get_fp_rounding_coefficient): Externalize.
external linkage.
* config/riscv/riscv.md (UNSPEC_LROUND): Remove.
(fix_trunc<ANYF:mode><GPR:mode>2): Replace with ...
(<fix_uns>_trunc<ANYF:mode>si2): New expander & associated insn.
(<fix_uns>_trunc<ANYF:mode>si2_ext): New insn.
(<fix_uns>_trunc<ANYF:mode>di2): Likewise.
(l<rint_pattern><ANYF:mode><GPR:mode>2): Replace with ...
(lrint<ANYF:mode>si2): New expander and associated insn.
(lrint<ANYF:mode>si2_ext, lrint<ANYF:mode>di2): New insns.
(<round_pattern><ANYF:mode>2): Replace with....
(l<round_pattern><ANYF:mode>si2): New expander and associated insn.
(l<round_pattern><ANYF:mode>si2_sext): New insn.
(l<round_pattern><ANYF:mode>di2): Likewise.
(<round_pattern><ANYF:mode>2): New expander.
gcc/testsuite/
* gcc.target/riscv/fix.c: New test.
* gcc.target/riscv/round.c: New test.
* gcc.target/riscv/round_32.c: New test.
* gcc.target/riscv/round_64.c: New test.
|
|
In my previous change I mistakenly changed Value_Range to
int_range<2>. The former has "infinite" precision for integer ranges,
whereas int_range<2> has two sub-ranges. This should have been
int_range_max.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Change
int_range<2> to int_range_max.
(memmodel_to_uhwi): Same.
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Same.
(determine_value_range): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
|
|
A large number of gm2 tests are timing out even on current Solaris/SPARC
systems. As detailed in the PR, the problem is that the gm2 testsuite
artificially lowers many timeouts way below the DejaGnu default of 300
seconds, often as short as 10 seconds. The problem lies both in the
values (they may be appropriate for some targets, but too low for
others, especially under high load) and the fact that it uses absolute
values, overriding e.g. settings from a build-wide site.exp.
Therefore this patch removes all those overrides, restoring the
defaults.
Tested on sparc-sun-solaris2.11 (where all the previous timeouts are
gone) and i386-pc-solaris2.11.
2024-04-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
PR modula2/114886
* lib/gm2.exp: Don't load timeout-dg.exp.
Don't set gm2_previous_timeout.
Don't call dg-timeout.
(gm2_push_timeout, gm2_pop_timeout): Remove.
(gm2_init): Don't call dg-timeout.
* lib/gm2-torture.exp: Don't load timeout-dg.exp.
Don't set gm2_previous_timeout.
Don't call dg-timeout.
(gm2_push_timeout, gm2_pop_timeout): Remove.
* gm2/coroutines/pim/run/pass/coroutines-pim-run-pass.exp: Don't
load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/examples/map/pass/examples-map-pass.exp: Don't call
gm2_push_timeout, gm2_pop_timeout.
* gm2/iso/run/pass/iso-run-pass.exp: Don't load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/pimlib/base/run/pass/pimlib-base-run-pass.exp: Don't load
timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/projects/iso/run/pass/halma/projects-iso-run-pass-halma.exp:
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/switches/whole-program/pass/run/switches-whole-program-pass-run.exp:
Don't load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
|
|
The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.
gcc/c/
* gimple-parser.cc (c_parser_gimple_binary_expression):
Parse __{CEIL,FLOOR,ROUND}_{DIV,MOD} and __EXACT_DIV.
gcc/testsuite/
* gcc.dg/gimplefe-53.c: New testcase.
|
|
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the non-trapping optab - we look at the result type
of the expression and check
trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
the bugreport correctly complains that -ftrapv affects pointer
subtraction (there's no -ftrapv-pointer). Now that we have
POINTER_DIFF_EXPR we can honor that appropriately.
The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
handling so they will never consider trapping (or saturating)
optabs.
PR middle-end/13421
* optabs-tree.cc (optab_for_tree_code): Do not consider
{add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
or POINTER_PLUS_EXPR.
|
|
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
|
|
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
Hongtao Liu <hongtao.liu@intel.com>
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN and
IFN_COND_MAX in the assert.
* gfortran.dg/pr114883.f90: New test.
|
|
While the C23 standard isn't officially release yet,
in 2011 we've changed __STDC_VERSION__ value for C11 already
in the month in which the new __STDC_VERSION__ value has been
finalized, so we want to change this now or wait
until we implement all the C23 features?
Note, seems Clang up to 17 also used 202000L for -std=c2x but
Clang 18+ uses 202311L as specified in the latest C23 drafts.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* init.cc (cpp_init_builtins): Change __STDC_VERSION__
for C23 from 202000L to 202311L.
* doc/cpp.texi (__STDC_VERSION__): Document 202311L value
for -std=c23/-std=gnu23.
|
|
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper mentions maybe_unused and gnu::nonstring attributes as examples
where they can be useful. Not sure about either of them.
For maybe_unused, the thing is that both GCC and clang already don't
diagnose maybe unused for the structured binding identifiers, because it
would be a false positive too often; and there is no easy way to find out
if a structured binding has been written with the P0609R3 paper in mind or
not (maybe we could turn it on if in the structured binding is any
attribute, even if just [[]] and record that as a flag on the whole
underlying decl, so that we'd diagnose
auto [a, b, c[[]]] = d;
// use a, c but not b
but not
auto [e, f, g] = d;
// use a, c but not b
). For gnu::nonstring, the issue is that we currently don't allow the
attribute on references to char * or references to char[], just on
char */char[]. I've filed a PR for that.
The first testcase in the patch tests it on [[]] and [[maybe_unused]],
just whether it is parsed properly, second on gnu::deprecated, which
works. Haven't used deprecated attribute because the paper said that
attribute is for further investigation.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR c++/114456
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_structured_bindings for C++26 to 202403L rather than
201606L.
gcc/cp/
* parser.cc (cp_parser_decomposition_declaration): Implement C++26
P0609R3 - Attributes for Structured Bindings. Parse attributed
identifier lists for structured binding declarations, pass the
attributes to start_decl.
gcc/testsuite/
* g++.dg/cpp26/decomp1.C: New test.
* g++.dg/cpp26/decomp2.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect
202403 rather than 201606.
|
|
When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a &TARGET_MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions. The following fixes this.
PR middle-end/114734
* internal-fn.cc (expand_call_mem_ref): Use
get_gimple_for_ssa_name to get at the def stmt of the address
argument to honor SSA coalescing constraints.
|
|
This patch fixes a number of issues with the handling of temploid friend
declarations.
The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.
The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden class template, that it
doesn't exist at all: it could be a non-exported entity that we've
nevertheless streamed in from an imported module. We need to ensure
that when instantiating template friend classes that we return the same
TEMPLATE_DECL that we got from our imports, otherwise we will get later
issues with 'duplicate_decls' (rightfully) complaining that they're
different when trying to merge.
This doesn't appear necessary for function templates due to the existing
name lookup handling already finding these hidden declarations.
PR c++/105320
PR c++/114275
gcc/cp/ChangeLog:
* cp-tree.h (propagate_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden decls can be
redeclared in this module.
* module.cc (imported_temploid_friends): New.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to a module.
(trees_in::decl_value): Read it.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New.
* name-lookup.cc (get_mergeable_namespace_binding): New.
(lookup_imported_hidden_friend): New.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends. Check
for valid module attachment of existing names. Propagate
defining module for new classes.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-10_a.C: New test.
* g++.dg/modules/tpl-friend-10_b.C: New test.
* g++.dg/modules/tpl-friend-10_c.C: New test.
* g++.dg/modules/tpl-friend-10_d.C: New test.
* g++.dg/modules/tpl-friend-11_a.C: New test.
* g++.dg/modules/tpl-friend-11_b.C: New test.
* g++.dg/modules/tpl-friend-12_a.C: New test.
* g++.dg/modules/tpl-friend-12_b.C: New test.
* g++.dg/modules/tpl-friend-12_c.C: New test.
* g++.dg/modules/tpl-friend-12_d.C: New test.
* g++.dg/modules/tpl-friend-12_e.C: New test.
* g++.dg/modules/tpl-friend-12_f.C: New test.
* g++.dg/modules/tpl-friend-13_a.C: New test.
* g++.dg/modules/tpl-friend-13_b.C: New test.
* g++.dg/modules/tpl-friend-13_c.C: New test.
* g++.dg/modules/tpl-friend-13_d.C: New test.
* g++.dg/modules/tpl-friend-13_e.C: New test.
* g++.dg/modules/tpl-friend-13_f.C: New test.
* g++.dg/modules/tpl-friend-13_g.C: New test.
* g++.dg/modules/tpl-friend-14_a.C: New test.
* g++.dg/modules/tpl-friend-14_b.C: New test.
* g++.dg/modules/tpl-friend-14_c.C: New test.
* g++.dg/modules/tpl-friend-14_d.C: New test.
* g++.dg/modules/tpl-friend-9.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Currently different places calling 'module_may_redeclare' all emit very
similar but slightly different error messages, and handle different
kinds of declarations differently. This patch makes the function
perform its own error messages so that they're all in one place, and
prepares it for use with temploid friends.
gcc/cp/ChangeLog:
* cp-tree.h (module_may_redeclare): Add default parameter.
* decl.cc (duplicate_decls): Don't emit errors for failed
module_may_redeclare.
(xref_tag): Likewise.
(start_enum): Likewise.
* semantics.cc (begin_class_definition): Likewise.
* module.cc (module_may_redeclare): Clean up logic. Emit error
messages on failure.
gcc/testsuite/ChangeLog:
* g++.dg/modules/enum-12.C: Update error message.
* g++.dg/modules/friend-5_b.C: Likewise.
* g++.dg/modules/shadow-1_b.C: Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
When adding to CLASSTYPE_BEFRIENDING_CLASSES as part of installing an
imported class definition, we need to look through TEMPLATE_DECL like
make_friend_class does.
Otherwise in the below testcase we won't add _Hashtable<int, int> to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base, which leads to a bogus
access check failure for _M_hash_code.
PR c++/114889
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
In the sizeof / sizeof operator expression handling we're missing
a dependence check for the second operand.
PR c++/114888
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op) <case *_DIV_*>: Add missing
dependence check for the second sizeof operand.
gcc/testsuite/ChangeLog:
* g++.dg/template/sizeof19.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
This reverts commit 05d83334d5bbeae01d71080f1da524810d6740d9.
|
|
Patch by Rainer Orth <ro@gcc.gnu.org>.
Fixes PR go/106813
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/581724
|
|
<stdbool.h> has been available since C99. Use it rather than defining
our own boolean type and values.
Fixes https://gcc.gnu.org/PR114875
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/582275
|
|
gcc/fortran/ChangeLog:
* expr.cc (check_transformational): Add SELECTED_LOGICAL_KIND
to allowed functions for Fortran 2023.
* gfortran.h (GFC_ISYM_SL_KIND): New.
* gfortran.texi: Mention SELECTED_LOGICAL_KIND.
* intrinsic.cc (add_functions): Add SELECTED_LOGICAL_KIND.
(gfc_intrinsic_func_interface): Allow it in initialization
expressions.
* intrinsic.h (gfc_simplify_selected_logical_kind): New proto.
* intrinsic.texi: Add SELECTED_LOGICAL_KIND.
* simplify.cc (gfc_simplify_selected_logical_kind): New
function.
* trans-decl.cc (gfc_build_intrinsic_function_decls): Initialize
gfor_fndecl_sl_kind.
* trans-intrinsic.cc (gfc_conv_intrinsic_sl_kind): New function.
(gfc_conv_intrinsic_function): Call it for GFC_ISYM_SL_KIND.
* trans.h (gfor_fndecl_sl_kind): New symbol.
gcc/testsuite/ChangeLog:
* gfortran.dg/selected_logical_kind_1.f90: New test.
* gfortran.dg/selected_logical_kind_2.f90: New test.
* gfortran.dg/selected_logical_kind_3.f90: New test.
* gfortran.dg/selected_logical_kind_4.f90: New test.
libgfortran/ChangeLog:
* gfortran.map: Add _gfortran_selected_logical_kind.
* intrinsics/selected_int_kind.f90: Add SELECTED_LOGICAL_KIND.
|
|
gcc/fortran/ChangeLog:
* iso-fortran-env.def: Add logical{8,16,32,64} and
real16 named constants.
gcc/testsuite/ChangeLog:
* gfortran.dg/iso_fortran_env_8.f90: New test.
* gfortran.dg/iso_fortran_env_9.f90: New test.
|
|
The adjacent_dr_p is sufficient and unnecessary condition for contiguous access.
So unnecessary live-ranges are added and result in smaller LMUL.
This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment
load/store.
Tested on RV64 and no regression.
PR target/114506
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (non_contiguous_memory_access_p): Rename
(need_additional_vector_vars_p): Rename and refine condition
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr114506.c: New test.
Signed-off-by: demin.han <demin.han@starfivetech.com>
|
|
2024-04-29 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/114959
* trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
if the default initializer has all NULL fields. Guard this
by a requirement that the code not be EXEC_INIT_ASSIGN and that
the object be an INTENT_OUT dummy.
* trans-stmt.cc (gfc_trans_allocate): Change the initializer
code for allocate with mold to EXEC_ALLOCATE to allow an
initializer with all NULL fields.
gcc/testsuite/
PR fortran/114959
* gfortran.dg/pr114959.f90: New test.
|
|
When we build with isl, there will be a ICE for graphite in both
the c/c++ and fortran. The legitimize move cannot take care of
below rtl.
(set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))
Then we will have ice similar to below:
internal compiler error: in extract_insn, at recog.cc:2812.
This patch would like to take care of the above rtl. Given the value of
const_poly_int can hardly excceed the max of int64, we can simply
consider the highest 8 bytes of TImode is zero and then set the dest
to (const_int 0).
The below test cases are fixed by this PATCH.
C:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)
Fortran:
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
The below test suites are passed for this patch:
* The rv64gcv fully regression test.
* The rv64gc fully regression test.
Try to write some RTL code for test but not works well according to
existing test cases. Thus, take above as test cases. Please note
graphite require the gcc build with isl.
PR target/114885
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
func impl to take care of (const_int_poly:TI 8).
(riscv_legitimize_move): Handle subreg is const_int_poly,
Signed-off-by: Pan Li <pan2.li@intel.com>
|
|
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
and all other affected Zic* extensions to riscv_zi_subext.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
zicclsm, and ziccrse into riscv_zi_subext.
* config/riscv/riscv.opt: Define MASK_ZIC64B for
riscv_ziccmo_subext.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
|
|
This patch adds the smin/smax RTL mode for the
min/max.fmt instructions.
Also, since the min/max.fmt instrucions applies to the
IEEE 754-2008 "minNum" and "maxNum" operations, this
patch also provides the new "fmin<mode>3" and
"fmax<mode>3" modes.
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_minmax): New
define_insn_reservation.
* config/mips/mips.h (ISA_HAS_FMIN_FMAX): Define new macro.
* config/mips/mips.md (UNSPEC_FMIN): New unspec.
(UNSPEC_FMAX): Same as above.
(type): Add fminmax.
(smin<mode>3): Generates MIN.fmt instructions.
(smax<mode>3): Generates MAX.fmt instructions.
(fmin<mode>3): Generates MIN.fmt instructions.
(fmax<mode>3): Generates MAX.fmt instructions.
* config/mips/p6600.md (p6600_fpu_fabs): Include fminmax
type.
gcc/testsuite/ChangeLog:
* gcc.target/mips/mips-minmax1.c: New test for MIPS R6.
* gcc.target/mips/mips-minmax2.c: Same as above.
|
|
|
|
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra saving/restoring involved in returning the changed
status, gives us a performance increase of 1.25% for VRP and 1.51% for
ipa-CP.
gcc/ChangeLog:
* tree-ssa-ccp.cc (ccp_finalize): Normalize before calling
set_bitmask.
* value-range.cc (irange::intersect_bitmask): Calculate changed
irange_bitmask bits on our own.
(irange::union_bitmask): Same.
(irange_bitmask::verify_mask): Verify that bits are normalized.
* value-range.h (irange_bitmask::union_): Do not normalize.
Remove return value.
(irange_bitmask::intersect): Same.
|
|
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range setters instead of out of line functions.
(pointer_min_max_operator::wi_fold): Same.
(pointer_and_operator::wi_fold): Same.
(pointer_or_operator::wi_fold): Same.
* range-op.cc (operator_negate::fold_range): Same.
(operator_addr_expr::fold_range): Same.
(range_op_cast_tests): Same.
* range.cc (range_zero): Remove.
(range_nonzero): Remove.
* range.h (range_zero): Remove.
(range_nonzero): Remove.
* value-range.cc (range_tests_misc): Use method instead of out of
line function.
|
|
Move some code out of the irange pretty printers so it can be shared
with pointers.
gcc/ChangeLog:
* value-range-pretty-print.cc (print_int_bound): New.
(print_irange_bitmasks): New.
(vrange_printer::print_irange_bound): Remove.
(vrange_printer::print_irange_bitmasks): Remove.
* value-range-pretty-print.h: Remove print_irange_bitmasks and
print_irange_bound
|
|
Accept a vrange, as this will be used for either integers or pointers.
gcc/ChangeLog:
* value-range.h (range_includes_zero_p): Accept vrange.
|
|
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range): Same.
* value-query.cc (range_query::get_tree_range): Handle both
integers and pointers.
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Make
r0 and r1 Value_Range's.
|
|
prange will also have bitmasks, so it will need to use get_bitmask_from_range.
gcc/ChangeLog:
* value-range.cc (get_bitmask_from_range): Move out of irange class.
(irange::get_bitmask): Call function instead of internal method.
* value-range.h (class irange): Remove get_bitmask_from_range.
|
|
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary friendship with
get_legacy_range.
(get_legacy_range): Accept a vrange.
|
|
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the frange code where a
range is being pessimized from [0.0, 1.0] to [-0.0, 1.0]. Exclude
checking frange's until this bug is fixed.
gcc/ChangeLog:
* value-range-storage.cc (irange_storage::set_irange): Move
verification code from here...
(vrange_storage::set_vrange): ...to here.
|
|
Make range_includes_zero_p take an argument instead of a pointer for
consistency in the range-op code.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_clz::fold_range): Change
range_includes_zero_p argument to a reference.
(cfn_ctz::fold_range): Same.
* range-op.cc (operator_plus::lhs_op1_relation): Same.
* value-range.h (range_includes_zero_p): Same.
|
|
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from range_true and range_false.
|
|
Now that we have a vrange storage class to save ranges in long-term
memory, there is no need for GTY markers for any of the vrange
classes, since they should never live in GC.
gcc/ChangeLog:
* value-range-storage.h: Remove friends.
* value-range.cc (gt_ggc_mx): Remove.
(gt_pch_nx): Remove.
* value-range.h (class vrange): Remove GTY markers.
(class irange): Same.
(class int_range): Same.
(class frange): Same.
(gt_ggc_mx): Remove.
(gt_pch_nx): Remove.
|
|
Any range can theoretically have a bitmask of set bits. This patch
moves the bitmask accessors to the base class. This cleans up some
users in IPA*, and will provide a cleaner interface when prange is in
place.
gcc/ChangeLog:
* ipa-cp.cc (propagate_bits_across_jump_function): Access bitmask
through base class.
(ipcp_store_vr_results): Same.
* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Same.
(ipcp_get_parm_bits): Same.
(ipcp_update_vr): Same.
* range-op-mixed.h (update_known_bitmask): Change argument to vrange.
* range-op.cc (update_known_bitmask): Same.
* value-range.cc (vrange::update_bitmask): New.
(irange::set_nonzero_bits): Move to vrange class.
(irange::get_nonzero_bits): Same.
* value-range.h (class vrange): Add update_bitmask, get_bitmask,
get_nonzero_bits, and set_nonzero_bits.
(class irange): Make bitmask methods virtual overrides.
(class Value_Range): Add get_bitmask and update_bitmask.
|
|
This patch adds vrange::lbound() and vrange::ubound() that return
trees. These can be used in generic code that is type agnostic, and
avoids special casing for pointers and integers in places where we
handle both. It also cleans up a wart in the Value_Range class.
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Convert
bound to wide_int.
* value-range.cc (Value_Range::lower_bound): Remove.
(Value_Range::upper_bound): Remove.
(unsupported_range::lbound): New.
(unsupported_range::ubound): New.
(frange::lbound): New.
(frange::ubound): New.
(irange::lbound): New.
(irange::ubound): New.
* value-range.h (class vrange): Add lbound() and ubound().
(class irange): Same.
(class frange): Same.
(class unsupported_range): Same.
(class Value_Range): Rename lower_bound and upper_bound to lbound
and ubound respectively.
|
|
Fix some Value_Range's that we know ahead of time will be only
integers. This avoids using the polymorphic Value_Range unnecessarily
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Make Value_Range an int_range.
(memmodel_to_uhwi): Same
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Same.
(determine_value_range): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
|
|
Richi mentioned in PR113476 that it would be cleaner to move the
destructor from int_range to the base class. Although this isn't
strictly necessary, as there are no users, it is good to future proof
things, and the overall impact is miniscule.
gcc/ChangeLog:
* value-range.h (vrange::~vrange): New.
(int_range::~int_range): Make final override.
|
