get_out_file did not follow the coding conventions (mixing three-space
and two-space indentation, missing linebreak before function name).
Take that as an excuse to reimplement it in a more terse manner and
rename as 'choose_output', which is hopefully more descriptive.
gcc/ChangeLog:
* genmatch.cc (get_out_file): Make static and rename to ...
(choose_output): ... this. Reimplement. Update all uses ...
(decision_tree::gen): ... here and ...
(main): ... here.
Eliminate boolean parameters of emit_func. The first ('open') just
prints 'extern' to generated header, which is unnecessary. Introduce a
separate function to use when finishing a declaration in place of the
second ('close').
Rename emit_func to 'fp_decl' (matching 'fprintf' in length) to unbreak
indentation in several places.
Reshuffle emitted line breaks in a few places to make generated
declarations less ugly.
gcc/ChangeLog:
* genmatch.cc (header_file): Make static.
(emit_func): Rename to...
(fp_decl): ... this. Adjust all uses.
(fp_decl_done): New function. Use it...
(decision_tree::gen): ... here and...
(write_predicate): ... here.
(main): Adjust.
aarch64: Avoid hard-coding specific register allocations
Some tests hard-coded specific allocations for temporary registers,
whereas the RA should be free to pick anything that doesn't force
unnecessary moves or spills.
Most governing predicate operands require p0-p7, but some
instructions also allow p8-p15. Non-gp uses of predicates
often also allow all of p0-p15.
This patch fixes up cases where we required p0-p7 unnecessarily.
In some cases we match the definition (typically a comparison,
PFALSE or PTRUE), sometimes we match the use (like a logic
instruction, MOV or SEL), and sometimes we match both.
aarch64: Relax ordering requirements in SVE dup tests
Some of the svdup tests expand to a SEL between two constant vectors.
This patch allows the constants to be formed in either order.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/asm/dup_s16.c: When using SEL to select
between two constant vectors, allow the constant moves to appear in
either order.
* gcc.target/aarch64/sve/acle/asm/dup_s32.c: Likewise.
* gcc.target/aarch64/sve/acle/asm/dup_s64.c: Likewise.
* gcc.target/aarch64/sve/acle/asm/dup_u16.c: Likewise.
* gcc.target/aarch64/sve/acle/asm/dup_u32.c: Likewise.
* gcc.target/aarch64/sve/acle/asm/dup_u64.c: Likewise.
aarch64: Allow moves after tied-register intrinsics
Some ACLE intrinsics map to instructions that tie the output
operand to an input operand. If all the operands are allocated
to different registers, and if MOVPRFX can't be used, we will need
a move either before the instruction or after it. Many tests only
matched the "before" case; this patch makes them accept the "after"
case too.
Some of the SVE ACLE asm tests tried to be agnostic about the
instruction order, but only one of the alternatives was exercised
in practice. This patch fixes latent typos in the other versions.
gcc/testsuite/
* gcc.target/aarch64/sve2/acle/asm/aesd_u8.c: Fix expected register
allocation in the case where a move occurs after the intrinsic
instruction.
* gcc.target/aarch64/sve2/acle/asm/aese_u8.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/aesimc_u8.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/aesmc_u8.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/sm4e_u32.c: Likewise.
If an insn requires two operands to be tied, and the input operand dies
in the insn, IRA acts as though there were a copy from the input to the
output with the same execution frequency as the insn. Allocating the
same register to the input and the output then saves the cost of a move.
If there is no such tie, but an input operand nevertheless dies
in the insn, IRA creates a similar move, but with an eighth of the
frequency. This helps to ensure that chains of instructions reuse
registers in a natural way, rather than using arbitrarily different
registers for no reason.
This heuristic seems to work well in the vast majority of cases.
However, the problem fixed in the previous patch was that we
could create a copy for an operand pair even if, for all relevant
alternatives, the output and input register classes did not have
any registers in common. It is then impossible for the output
operand to reuse the dying input register.
This left unfixed a further case where copies don't make sense:
there is no point trying to reuse the dying input register if,
for all relevant alternatives, the output is earlyclobbered and
the input doesn't match the output. (Matched earlyclobbers are fine.)
Handling that case fixes several existing XFAILs and helps with
a follow-on aarch64 patch.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. A SPEC2017 run
on aarch64 showed no differences outside the noise. Also, I tried
compiling gcc.c-torture, gcc.dg, and g++.dg for at least one target
per cpu directory, using the options -Os -fno-schedule-insns{,2}.
The results below summarise the tests that showed a difference in LOC:
with other targets showing no sensitivity to the patch. The only
target that seems to be negatively affected is m32r-elf; otherwise
the patch seems like an extremely minor but still clear improvement.
gcc/
* ira-conflicts.cc (can_use_same_reg_p): Skip over non-matching
earlyclobbers.
This is a repost/respin of a patch that was conditionally approved:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609470.html
This patch adds a convenient post-reload splitter for setting/updating
the highpart of a TImode variable, using i386's previously added
split_double_concat infrastructure.
For the new test case below:
__int128 foo(__int128 x, unsigned long long y)
{
__int128 t = (__int128)y << 64;
__int128 r = (x & ~0ull) | t;
return r;
}
with this patch, GCC instead now generates the much better:
foo: movq %rdi, %rcx
movq %rcx, %rax
ret
It turns out that the -m32 equivalent of this testcase, already
avoids using explict orl/xor instructions, as it gets optimized
(in combine) by a completely different path. Given that this idiom
isn't seen in 32-bit code (so this pattern doesn't match with -m32),
and also that the shorter 32-bit AND bitmask is represented as a
CONST_INT rather than a CONST_WIDE_INT, this new define_insn_and_split
is implemented for just TARGET_64BIT rather than contort a "generic"
implementation using DWI mode iterators.
2023-05-08 Roger Sayle <roger@nextmovesoftware.com>
Uros Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
* config/i386/i386.md (any_or_plus): Move definition earlier.
(*insvti_highpart_1): New define_insn_and_split to overwrite
(insv) the highpart of a TImode register/memory.
gcc/testsuite/ChangeLog
* gcc.target/i386/insvti_highpart-1.c: New test case.
Eugene Rozenfeld [Tue, 28 Feb 2023 23:58:40 +0000 (15:58 -0800)]
Fix cfg maintenance after inlining in AutoFDO
Todo from early_inliner needs to be propagated so that
cleanup_tree_cfg () is called if necessary.
This bug was causing an assert in get_loop_body during
ipa-sra in autoprofiledbootstrap build since loops weren't
fixed up and one of the loops had num_nodes set to 0.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
* auto-profile.cc (auto_profile): Check todo from early_inline
to see if cleanup_tree_vfg needs to be called.
(early_inline): Return todo from early_inliner.
Andrew Pinski [Mon, 8 May 2023 17:58:06 +0000 (10:58 -0700)]
Fix pr81192.c for int16 targets
I had missed when converting this
testcase to Gimple that there was a define
for int/unsigned type specifically to get
an INT32 type. This means when using a
literal integer constant you need to use the
`_Literal (type)` to form the types correctly on the
constants.
This fixes the issue and has been both tested on
xstormy16-elf and x86_64-linux-gnu.
Committed as obvious.
gcc/testsuite/ChangeLog:
PR testsuite/109776
* gcc.dg/pr81192.c: Fix integer constants for int16 targets.
Kito Cheng [Mon, 8 May 2023 13:44:30 +0000 (21:44 +0800)]
RISC-V: Improve portability of testcases
stdint.h will require having corresponding multi-lib existing, so using
stdint-gcc.h instead, also added a riscv_vector.h wrapper to
gcc.target/riscv/rvv/autovec/.
Jeff Law [Mon, 8 May 2023 14:28:26 +0000 (08:28 -0600)]
Fix minor length computation on stormy16
Today's build of xstormy16-elf failed due to a branch to an out of range
target. Manual inspection of the assembly code for the affected function
(divdi3) showed that the zero-extension patterns were claiming a length
of 2, but clearly assembled into 4 bytes.
This patch adds an explicit length to the zero extension pattern and
appears to resolve the issue in my test builds.
That is, if 'c.exp' executes first, it does successfully evaluate
'dg-require-effective-target openacc_cublas' -- and does cache this result (so
it isn't reevaluated for 'c++.exp'). However, for 'c++.exp' alone (that is,
without the 'c.exp' result cached), we run into:
spawn -ignore SIGHUP [xgcc] [...] -x c++ openacc_cublas2311907.c [...]
In file included from /usr/include/cuda_fp16.h:3673,
from /usr/include/cublas_api.h:75,
from /usr/include/cublas_v2.h:65,
from openacc_cublas2311907.c:3:
/usr/include/cuda_fp16.hpp:67:10: fatal error: utility: No such file or directory
We're missing include paths to C++/libstdc++ build-tree headers.
Fix this by using the mechanism introduced for Fortran in
r212268 (commit f707da16f714f7fe5a42391748212c84dfec639b) re
"libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}".
libgomp/
* testsuite/libgomp.c++/c++.exp: Use 'lang_include_flags' instead
of 'libstdcxx_includes'.
* testsuite/libgomp.oacc-c++/c++.exp: Likewise.
Thomas Schwinge [Tue, 2 May 2023 17:57:47 +0000 (19:57 +0200)]
Let each 'lto_init' determine the default 'LTO_OPTIONS', and 'torture-init' the 'LTO_TORTURE_OPTIONS'
Otherwise, for example for 'RUNTESTFLAGS' of '--target_board=unix\{-m64,-m32\}'
vs. '--target_board=unix\{-m32,-m64\}', both variants exercise testing with
always the first flag variant's 'LTO_OPTIONS'/'LTO_TORTURE_OPTIONS', which
results in unequal test results between the two 'RUNTESTFLAGS' variants if one
of the flag variants has 'check_linker_plugin_available' but the other doesn't.
Patrick Palka [Mon, 8 May 2023 13:03:35 +0000 (09:03 -0400)]
c++: list CTAD and resolve_nondeduced_context [PR106214]
This extends the PR93107 fix, which made us do resolve_nondeduced_context
on the elements of an initializer list during auto deduction, to happen for
CTAD as well.
PR c++/106214
PR c++/93107
gcc/cp/ChangeLog:
* pt.cc (do_auto_deduction): Move up resolve_nondeduced_context
calls to happen before do_class_deduction. Add some
error_mark_node tests.
The new __dmr type that is being added as a possible future PowerPC instruction
set bumps into a structure field size issue. The size of the __dmr type is 1024 bits.
The precision field in tree_type_common is currently 10 bits, so if you store
1,024 into field, you get a 0 back. When you get 0 in the precision field, the
ccp pass passes this 0 to sext_hwi in hwint.h. That function in turn generates
a shift that is equal to the host wide int bit size, which is undefined as
machine dependent for shifting in C/C++.
It turns out the x86_64 where I first did my tests returns the original input
before the two shifts, while the PowerPC always returns 0. In the ccp pass, the
original input is -1, and so it worked. When I did the runs on the PowerPC, the
result was 0, which ultimately led to the failure.
2023-02-01 Richard Biener <rguenther@suse.de>
Michael Meissner <meissner@linux.ibm.com>
PR middle-end/108623
* tree-core.h (tree_type_common): Bump up precision field to 16 bits.
Align bit fields > 1 bit to at least an 8-bit boundary.
Andrew Pinski [Thu, 27 Apr 2023 19:21:54 +0000 (12:21 -0700)]
PHIOPT: factor out unary operations instead of just conversions
After using factor_out_conditional_conversion with diamond bb,
we should be able do use it also for all normal unary gimple and not
just conversions. This allows to optimize PR 59424 for an example.
This is also a start to optimize PR 64700 and a few others.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
An example of this is:
```
static inline unsigned long long g(int t)
{
unsigned t1 = t;
return t1;
}
static int abs1(int a)
{
if (a < 0)
a = -a;
return a;
}
unsigned long long f(int c, int d, int e)
{
unsigned long long t;
if (d > e)
t = g(abs1(d));
else
t = g(abs1(e));
return t;
}
```
Which should be optimized to:
_9 = MAX_EXPR <d_5(D), e_6(D)>;
_4 = ABS_EXPR <_9>;
t_3 = (long long unsigned intD.16) _4;
gcc/ChangeLog:
* tree-ssa-phiopt.cc (factor_out_conditional_conversion): Rename to ...
(factor_out_conditional_operation): This and add support for all unary
operations.
(pass_phiopt::execute): Update call to factor_out_conditional_conversion
to call factor_out_conditional_operation instead.
* gcc.dg/tree-ssa/abs-2.c: Update tree scan for
details change in wording.
* gcc.dg/tree-ssa/minmax-17.c: Likewise.
* gcc.dg/tree-ssa/pr103771.c: Likewise.
* gcc.dg/tree-ssa/minmax-18.c: New test.
* gcc.dg/tree-ssa/minmax-19.c: New test.
Andrew Pinski [Thu, 27 Apr 2023 16:50:43 +0000 (09:50 -0700)]
PHIOPT: Loop over calling factor_out_conditional_conversion
After adding diamond shaped bb support to factor_out_conditional_conversion,
we can get a case where we have two conversions that needs factored out
and then would have another phiopt happen.
An example is:
```
static inline unsigned long long g(int t)
{
unsigned t1 = t;
return t1;
}
unsigned long long f(int c, int d, int e)
{
unsigned long long t;
if (c > d)
t = g(c);
else
t = g(d);
return t;
}
```
In this case we should get a MAX_EXPR in phiopt1 with two casts.
Before this patch, we would just factor out the outer cast and then
wait till phiopt2 to factor out the inner cast.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (pass_phiopt::execute): Loop
over factor_out_conditional_conversion.
Andrew Pinski [Wed, 26 Apr 2023 21:55:46 +0000 (14:55 -0700)]
PHIOPT: Add diamond bb form to factor_out_conditional_conversion
So the function factor_out_conditional_conversion already supports
diamond shaped bb forms, just need to be called for such a thing.
harden-cond-comp.c needed to be changed as we would optimize out the
conversion now and that causes the compare hardening not needing to
split the block which it was testing. So change it such that there
would be no chance of optimization.
Also add two testcases that showed the improvement. PR 103771 is
solved in ifconvert also for the vectorizer but now it is solved
in a general sense.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
* tree-ssa-phiopt.cc (pass_phiopt::execute): Support
Diamond shapped bb form for factor_out_conditional_conversion.
gcc/testsuite/ChangeLog:
* c-c++-common/torture/harden-cond-comp.c: Change testcase
slightly to avoid the new phiopt optimization.
* gcc.dg/tree-ssa/abs-2.c: New test.
* gcc.dg/tree-ssa/pr103771.c: New test.
Juzhe-Zhong [Mon, 8 May 2023 03:41:43 +0000 (11:41 +0800)]
RISC-V: Fix ugly && incorrect codes of RVV auto-vectorization
1. Add movmisalign pattern for TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
targethook, current RISC-V has supported this target hook, we can't make
it supported without movmisalign pattern.
2. Remove global extern of get_mask_policy_no_pred && get_tail_policy_no_pred.
These 2 functions are comming from intrinsic builtin frameworks.
We are sure we don't need them in auto-vectorization implementation.
3. Refine mask mode implementation.
4. We should not have "riscv_vector_" in riscv_vector namspace since it
makes the codes inconsistent and ugly.
For example:
Before this patch:
static opt_machine_mode
riscv_get_mask_mode (machine_mode mode)
{
machine_mode mask_mode = VOIDmode;
if (TARGET_VECTOR && riscv_vector::riscv_vector_get_mask_mode (mode).exists (&mask_mode))
return mask_mode;
..
After this patch:
riscv_get_mask_mode (machine_mode mode)
{
machine_mode mask_mode = VOIDmode;
if (TARGET_VECTOR && riscv_vector::get_mask_mode (mode).exists (&mask_mode))
return mask_mode;
..
Kito Cheng [Thu, 4 May 2023 07:12:27 +0000 (15:12 +0800)]
RISC-V: Handle multi-lib path correclty for linux
RISC-V Linux encodes the ABI into the path, so in theory, we can only use that
to select multi-lib paths, and no way to use different multi-lib paths between
`rv32i/ilp32` and `rv32ima/ilp32`, we'll mapping both to `/lib/ilp32`.
It's hard to do that with GCC's builtin multi-lib selection mechanism; builtin
mechanism did the option string compare and then enumerate all possible reuse
rules during the build time. However, it's impossible to RISC-V; we have a huge
number of combinations of `-march`, so implementing a customized multi-lib
selection becomes the only solution.
Multi-lib configuration is only used for determines which ISA should be used
when compiling the corresponding ABI variant after this patch.
During the multi-lib selection stage, only consider -mabi as the only key to
select the multi-lib path.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_select_multilib_by_abi): New.
(riscv_select_multilib): New.
(riscv_compute_multilib): Extract logic to riscv_select_multilib and
also handle select_by_abi.
* config/riscv/elf.h (RISCV_USE_CUSTOMISED_MULTI_LIB): Change it
to select_by_abi_arch_cmodel from 1.
* config/riscv/linux.h (RISCV_USE_CUSTOMISED_MULTI_LIB): Define.
* config/riscv/riscv-opts.h (enum riscv_multilib_select_kind): New.
Makefile.in: clean up match.pd-related dependencies
Clean up confusing changes from the recent refactoring for
parallel match.pd build.
gimple-match-head.o is not built. Remove related flags adjustment.
Autogenerated gimple-match-N.o files do not depend on
gimple-match-exports.cc.
{gimple,generic)-match-auto.h only depend on the prerequisites of the
corresponding s-{gimple,generic}-match stamp file, not any .cc file.
gcc/ChangeLog:
* Makefile.in: (gimple-match-head.o-warn): Remove.
(GIMPLE_MATCH_PD_SEQ_SRC): Do not depend on
gimple-match-exports.cc.
(gimple-match-auto.h): Only depend on s-gimple-match.
(generic-match-auto.h): Likewise.
Andrew Pinski [Tue, 2 May 2023 07:10:46 +0000 (00:10 -0700)]
Move substitute_and_fold over to use simple_dce_from_worklist
While looking into a different issue, I noticed that it
would take until the second forwprop pass to do some
forward proping and it was because the ssa name was
used more than once but the second statement was
"dead" and we don't remove that until much later.
So this uses simple_dce_from_worklist instead of manually
removing of the known unused statements instead.
Propagate engine does not do a cleanupcfg afterwards either but manually
cleans up possible EH edges so simple_dce_from_worklist
needs to communicate that back to the propagate engine.
Some testcases needed to be updated/changed even because of better optimization.
gcc.dg/pr81192.c even had to be changed to be using the gimple FE so it would
be less fragile in the future too.
gcc.dg/tree-ssa/pr98737-1.c was failing because __atomic_fetch_ was being matched
but in those cases, the result was not being used so both __atomic_fetch_ and
__atomic_x_and_fetch_ are valid choices and would not make a code generation difference.
evrp7.c, evrp8.c, vrp35.c, vrp36.c: just needed a slightly change as the removal message
is different slightly.
kernels-alias-8.c: ccp1 is able to remove an unused load which causes ealias to have
one less load to analysis so update the expected scan #.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/109691
* tree-ssa-dce.cc (simple_dce_from_worklist): Add need_eh_cleanup
argument.
If the removed statement can throw, have need_eh_cleanup
include the bb of that statement.
* tree-ssa-dce.h (simple_dce_from_worklist): Update declaration.
* tree-ssa-propagate.cc (struct prop_stats_d): Remove
num_dce.
(substitute_and_fold_dom_walker::substitute_and_fold_dom_walker):
Initialize dceworklist instead of stmts_to_remove.
(substitute_and_fold_dom_walker::~substitute_and_fold_dom_walker):
Destore dceworklist instead of stmts_to_remove.
(substitute_and_fold_dom_walker::before_dom_children):
Set dceworklist instead of adding to stmts_to_remove.
(substitute_and_fold_engine::substitute_and_fold):
Call simple_dce_from_worklist instead of poping
from the list.
Don't update the stat on removal statements.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/evrp7.c: Update for output change.
* gcc.dg/tree-ssa/evrp8.c: Likewise.
* gcc.dg/tree-ssa/vrp35.c: Likewise.
* gcc.dg/tree-ssa/vrp36.c: Likewise.
* gcc.dg/tree-ssa/pr98737-1.c: Update scan-tree-dump-not
to check for assignment too instead of just a call.
* c-c++-common/goacc/kernels-alias-8.c: Update test
for removal of load.
* gcc.dg/pr81192.c: Rewrite testcase in gimple based test.
Patrick Palka [Sun, 7 May 2023 16:09:03 +0000 (12:09 -0400)]
c++: goto entering scope of obj w/ non-trivial dtor [PR103091]
It seems ever since DR 2256 goto is permitted to cross the initialization
of a trivially initialized object with a non-trivial destructor. We
already supported this as an -fpermissive extension, so this patch just
makes us unconditionally support this.
DR 2256
PR c++/103091
gcc/cp/ChangeLog:
* decl.cc (decl_jump_unsafe): Return bool instead of int.
Don't consider TYPE_HAS_NONTRIVIAL_DESTRUCTOR.
(check_previous_goto_1): Simplify now that decl_jump_unsafe
returns bool instead of int.
(check_goto): Likewise.
gcc/testsuite/ChangeLog:
* g++.old-deja/g++.other/init9.C: Don't expect diagnostics for
goto made valid by DR 2256.
* g++.dg/init/goto4.C: New test.
Patrick Palka [Sun, 7 May 2023 16:05:24 +0000 (12:05 -0400)]
c++: satisfaction of non-dep member alias template-id
constraints_satisfied_p already carefully checks dependence of template
arguments before proceeding with satisfaction, so the dependence check
in instantiate_alias_template is unnecessary and overly conservative.
Getting rid of it allows us to check satisfaction ahead of time in more
cases as in the below testcase.
gcc/cp/ChangeLog:
* pt.cc (instantiate_alias_template): Exit early upon
error from coerce_template_parms. Remove dependence test
guarding constraints_satisfied_p.
Patrick Palka [Sun, 7 May 2023 16:02:16 +0000 (12:02 -0400)]
c++: various code cleanups
* Harden some tree accessor macros and fix a couple of bad
PLACEHOLDER_TYPE_CONSTRAINTS accesses uncovered by this.
* Use strip_innermost_template_args in outer_template_args.
* Add !processing_template_decl early exit tests to some dependence
predicates.
gcc/cp/ChangeLog:
* cp-tree.h (PLACEHOLDER_TYPE_CONSTRAINTS_INFO): Harden via
TEMPLATE_TYPE_PARM_CHECK.
(TPARMS_PRIMARY_TEMPLATE): Harden via TREE_VEC_CHECK.
(TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL): Harden via
TEMPLATE_TEMPLATE_PARM_CHECK.
* cxx-pretty-print.cc (cxx_pretty_printer::simple_type_specifier):
Guard PLACEHOLDER_TYPE_CONSTRAINTS access.
* error.cc (dump_type) <case TEMPLATE_TYPE_PARM>: Use separate
variable to store CLASS_PLACEHOLDER_TEMPLATE result.
* pt.cc (outer_template_args): Use strip_innermost_template_args.
(any_type_dependent_arguments_p): Exit early if
!processing_template_decl. Use range-based for.
(any_dependent_template_arguments_p): Likewise.
Patrick Palka [Sun, 7 May 2023 15:57:22 +0000 (11:57 -0400)]
c++: parenthesized -> resolving to static data member [PR98283]
Here we're neglecting to propagate parenthesized-ness when the
member access (this->m) resolves to a static data member (and
thus finish_class_member_access_expr yields a VAR_DECL instead
of a COMPONENT_REF).
PR c++/98283
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy_and_build) <case COMPONENT_REF>: Propagate
REF_PARENTHESIZED_P more generally via force_paren_expr.
* semantics.cc (force_paren_expr): Document default argument.
Patrick Palka [Sun, 7 May 2023 15:54:21 +0000 (11:54 -0400)]
c++: bound ttp in lambda function type [PR109651]
After r14-11-g2245459c85a3f4 we now coerce the template arguments of a
bound ttp again after level-lowering it. Notably a level-lowered ttp
doesn't have DECL_CONTEXT set, so during this coercion we fall back to
using current_template_parms to obtain the relevant set of in-scope
parameters.
But it turns out current_template_parms isn't properly set when
substituting the function type of a generic lambda, and so if the type
contains bound ttps that need to be lowered we'll crash during their
attempted coercion. Specifically in the first testcase below,
current_template_parms during the lambda type substitution (with T=int)
is "1 U" instead of the expected "2 TT, 1 U", and we crash when level
lowering TT<int>.
Ultimately the problem is that tsubst_lambda_expr does things in the
wrong order: we ought to substitute (and install) the in-scope template
parameters _before_ substituting anything that may use those template
parameters (such as the function type of a generic lambda). This patch
corrects this substitution order.
PR c++/109651
gcc/cp/ChangeLog:
* pt.cc (coerce_template_args_for_ttp): Mention we can hit the
current_template_parms fallback when level-lowering a bound ttp.
(tsubst_template_decl): Add lambda_tparms parameter. Prefer to
use lambda_tparms instead of substituting DECL_TEMPLATE_PARMS.
(tsubst_decl) <case TEMPLATE_DECL>: Pass NULL_TREE as lambda_tparms
to tsubst_template_decl.
(tsubst_lambda_expr): For a generic lambda, substitute
DECL_TEMPLATE_PARMS and set current_template_parms to it
before substituting the function type. Pass the substituted
DECL_TEMPLATE_PARMS as lambda_tparms to tsubst_template_decl.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-generic-ttp1.C: New test.
* g++.dg/cpp2a/lambda-generic-ttp2.C: New test.
Andrew Pinski [Sun, 7 May 2023 01:38:17 +0000 (01:38 +0000)]
Fix aarch64/109762: push_options/push_options does not work sometimes
aarch64_isa_flags (and aarch64_asm_isa_flags) are both aarch64_feature_flags (uint64_t)
but since r12-8000-g14814e20161d, they are saved/restored as unsigned long. This
does not make a difference for LP64 targets but on ILP32 and LLP64IL32 targets,
it means it does not get restored correctly.
This patch changes over to use aarch64_feature_flags instead of unsigned long.
Committed as obvious after a bootstrap/test.
gcc/ChangeLog:
PR target/109762
* config/aarch64/aarch64-builtins.cc (aarch64_simd_switcher::aarch64_simd_switcher):
Change argument type to aarch64_feature_flags.
* config/aarch64/aarch64-protos.h (aarch64_simd_switcher): Change
constructor argument type to aarch64_feature_flags.
Change m_old_asm_isa_flags to be aarch64_feature_flags.
Patrick Palka [Sun, 7 May 2023 14:24:52 +0000 (10:24 -0400)]
c++: non-dep init folding and access checking [PR109480]
enforce_access currently checks processing_template_decl to decide
whether to defer the given access check until instantiation time.
But using this flag is unreliable because it gets cleared during e.g.
non-dependent initializer folding, and so can lead to premature access
check failures as in the below testcase. It seems better to check
current_template_parms instead.
PR c++/109480
gcc/cp/ChangeLog:
* semantics.cc (enforce_access): Check current_template_parms
instead of processing_template_decl when deciding whether to
defer the access check.
Patrick Palka [Sun, 7 May 2023 14:24:49 +0000 (10:24 -0400)]
c++: potentiality of templated memfn call [PR109480]
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being non-constexpr,
which leads to us needlessly instantiating the initializer ahead of time
and which subsequently triggers a bug in access checking deferral (to be
fixed by the follow-up patch).
This patch fixes this by calling get_fns earlier during CALL_EXPR
potentiality checking so that when we extract a FUNCTION_DECL out of a
templated member function call (whose overall callee is typically a
COMPONENT_REF) we do the usual constexpr-eligibility checking for it.
In passing, I noticed the nearby special handling of the object argument
of a non-static member function call is effectively the same as the
generic argument handling a few lines below. So this patch just gets
rid of this special handling; otherwise we'd have to adapt it to handle
templated versions of such calls.
PR c++/109480
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>:
Reorganize to call get_fns sooner. Remove special handling of
the object argument of a non-static member function call. Remove
dead store to 'fun'.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept59.C: Make e() constexpr so that the
expected "without object" diagnostic isn't replaced by a
"call to non-constexpr function" diagnostic.
* g++.dg/template/non-dependent25.C: New test.
Jiufu Guo [Wed, 4 Jan 2023 06:27:30 +0000 (14:27 +0800)]
rs6000: Load high and low part of 64bit constant independently
Compare with previous version, this patch updates the comments only.
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608293.html
For a complicate 64bit constant, below is one instruction-sequence to
build:
lis 9,0x800a
ori 9,9,0xabcd
sldi 9,9,32
oris 9,9,0xc167
ori 9,9,0xfa16
while we can also use below sequence to build:
lis 9,0xc167
lis 10,0x800a
ori 9,9,0xfa16
ori 10,10,0xabcd
rldimi 9,10,32,0
This sequence is using 2 registers to build high and low part firstly,
and then merge them.
In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
register with potential register pressure).
The instruction sequence with two registers for parallel version can be
generated only if can_create_pseudo_p. Otherwise, the one register
sequence is generated.
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Generate
more parallel code if can_create_pseudo_p.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/parall_5insn_const.c: New test.
Roger Sayle [Sun, 7 May 2023 06:52:15 +0000 (07:52 +0100)]
Don't call emit_clobber in lower-subreg.cc's resolve_simple_move.
Following up on posts/reviews by Segher and Uros, there's some question
over why the middle-end's lower subreg pass emits a clobber (of a
multi-word register) into the instruction stream before emitting the
sequence of moves of the word-sized parts. This clobber interferes
with (LRA) register allocation, preventing the multi-word pseudo to
remain in the same hard registers. This patch eliminates this
(presumably superfluous) clobber and thereby improves register allocation.
A concrete example of the observed improvement is PR target/43644.
For the test case:
__int128 foo(__int128 x, __int128 y) { return x+y; }
on x86_64-pc-linux-gnu, gcc -O2 currently generates:
RISC-V: autovec: Verify that GET_MODE_NUNITS is a multiple of 2.
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.
Tested on RISCV and x86_64-linux-gnu. Okay?
gcc/
* tree-vect-slp.cc (can_duplicate_and_interleave_p):
Check that GET_MODE_NUNITS is a multiple of 2.
Xi Ruoyao [Sun, 23 Apr 2023 12:52:22 +0000 (20:52 +0800)]
LoongArch: Enable shrink wrapping
This commit implements the target macros for shrink wrapping of function
prologues/epilogues shrink wrapping on LoongArch.
Bootstrapped and regtested on loongarch64-linux-gnu. I don't have an
access to SPEC CPU so I hope the reviewer can perform a benchmark to see
if there is real benefit.
Xi Ruoyao [Sat, 15 Apr 2023 11:55:50 +0000 (19:55 +0800)]
build: Use -nostdinc generating macro_list [PR109522]
This prevents a spurious message building a cross-compiler when target
libc is not installed yet:
cc1: error: no include path in which to search for stdc-predef.h
As stdc-predef.h was added to define __STDC_* macros by libc, it's
unlikely the header will ever contain some bad definitions w/o "__"
prefix so it should be safe.
gcc/ChangeLog:
PR other/109522
* Makefile.in (s-macro_list): Pass -nostdinc to
$(GCC_FOR_TARGET).
* config/riscv/riscv-protos.h (preferred_simd_mode): New function.
* config/riscv/riscv-v.cc (autovec_use_vlmax_p): Ditto.
(preferred_simd_mode): Ditto.
* config/riscv/riscv.cc (riscv_get_arg_info): Handle RVV type in function arg.
(riscv_convert_vector_bits): Adjust for RVV auto-vectorization.
(riscv_preferred_simd_mode): New function.
(TARGET_VECTORIZE_PREFERRED_SIMD_MODE): New target hook support.
* config/riscv/vector.md: Add autovec.md.
* config/riscv/autovec.md: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Add testcases for RVV auto-vectorization.
* gcc.target/riscv/rvv/autovec/fixed-vlmax-1.c: New test.
* gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.c: New test.
* gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.h: New test.
* gcc.target/riscv/rvv/autovec/partial/single_rgroup_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/scalable-1.c: New test.
* gcc.target/riscv/rvv/autovec/template-1.h: New test.
* gcc.target/riscv/rvv/autovec/v-1.c: New test.
* gcc.target/riscv/rvv/autovec/v-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve32f-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve32f-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve32f-3.c: New test.
* gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve32f_zvl128b-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve32x-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve32x-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve32x-3.c: New test.
* gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve32x_zvl128b-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64d-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64d-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64d-3.c: New test.
* gcc.target/riscv/rvv/autovec/zve64d_zvl128b-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64d_zvl128b-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64f-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64f-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64f-3.c: New test.
* gcc.target/riscv/rvv/autovec/zve64f_zvl128b-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64f_zvl128b-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64x-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64x-2.c: New test.
* gcc.target/riscv/rvv/autovec/zve64x-3.c: New test.
* gcc.target/riscv/rvv/autovec/zve64x_zvl128b-1.c: New test.
* gcc.target/riscv/rvv/autovec/zve64x_zvl128b-2.c: New test.
Dan Horák [Wed, 3 May 2023 19:29:09 +0000 (14:29 -0500)]
libffi: fix handling of homogeneous float128 structs (#689)
If there is a homogeneous struct with float128 members, they should be
copied to vector register save area. The current code incorrectly copies
only the value of the first member, not increasing the pointer with each
iteration. Fix this.
Jakub Jelinek [Sat, 6 May 2023 08:57:41 +0000 (10:57 +0200)]
gimple-range-op: Improve handling of sin/cos ranges
Similarly to the earlier sqrt patch, this patch attempts to improve
sin/cos ranges. As the functions are periodic, for the reverse range
there is not much we can do (but I've discovered I forgot to take
into account the boundary ulps for the discovery of impossible result
ranges). For fold_range, we can do something only if the range is
narrow enough (narrower than 2*pi). The patch computes the value of
the functions (taking ulps into account) and also computes the derivative
to find out if the function is growing or declining on the boundaries and
from that it figures out if the result range should be
[min (fn (lb), fn (ub)), max (fn (lb), fn (ub))] or if it needs to be
extended to 1 (actually using +Inf) and/or -1 (actually using -Inf) because
there must be a local minimum and/or maximum in the range.
2023-05-06 Jakub Jelinek <jakub@redhat.com>
* real.h (dconst_pi): Define.
(dconst_e_ptr): Formatting fix.
(dconst_pi_ptr): Declare.
* real.cc (dconst_pi_ptr): New function.
* gimple-range-op.cc (cfn_sincos::fold_range): Intersect the generic
boundaries range with range computed from sin/cos of the particular
bounds if the argument range is shorter than 2*pi.
(cfn_sincos::op1_range): Take bulps into account when determining
which result ranges are always invalid or behave like known NAN.
Aldy Hernandez [Wed, 3 May 2023 08:48:41 +0000 (10:48 +0200)]
Remove type from vrange_storage::equal_p.
The equal_p method in vrange_storage is only used to compare ranges
that are the same type. No sense passing the type if it can be
determined from the range being compared.
gcc/ChangeLog:
* gimple-range-cache.cc (sbr_sparse_bitmap::set_bb_range): Do not
pass type to vrange_storage::equal_p.
* value-range-storage.cc (vrange_storage::equal_p): Remove type.
(irange_storage::equal_p): Same.
(frange_storage::equal_p): Same.
* value-range-storage.h (class frange_storage): Same.
Since we have backward demand fusion in Phase 1, so the real demand of "vle8.v" is e32, m4.
However, if we use parse_insn (vle8.v) = e8, m1 which is not correct.
So this patch we change new_info = new_info.parse_insn (i)
into:
Since m_vector_manager->vector_insn_infos is the member variable of pass_vsetvl class.
We remove static void function "local_eliminate_vsetvl_insn", and make it as the member function
of pass_vsetvl class.
PR target/109748
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (local_eliminate_vsetvl_insn): Remove it.
(pass_vsetvl::local_eliminate_vsetvl_insn): New function.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr109748.c: New test.
liuhongt [Tue, 21 Mar 2023 05:35:06 +0000 (13:35 +0800)]
Canonicalize vec_merge when mask is constant.
Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.
The canonicalization should help backends for pattern match. .i.e. x86
backend has lots of vec_merge patterns, combine will create any form
of vec_merge(mask, or inverted mask), then backend need to add 2
patterns to match exact 1 instruction. The canonicalization can
simplify 2 patterns to 1.
gcc/ChangeLog:
* combine.cc (maybe_swap_commutative_operands): Canonicalize
vec_merge when mask is constant.
* doc/md.texi: Document vec_merge canonicalization.
Jakub Jelinek [Sat, 6 May 2023 00:35:02 +0000 (02:35 +0200)]
gimple-range-op: Improve handling of sqrt ranges
The previous patch just added basic intrinsic ranges for sqrt
([-0.0, +Inf] +-NAN being the general result range of the function
and [-0.0, +Inf] the general operand range if result isn't NAN etc.),
the following patch intersects those ranges with particular range
computed from argument or result's exact range with the expected
error in ulps taken into account and adds a function (frange_arithmetic
variant) which can be used by other functions as well as helper.
2023-05-06 Jakub Jelinek <jakub@redhat.com>
* value-range.h (frange_arithmetic): Declare.
* range-op-float.cc (frange_arithmetic): No longer static.
* gimple-range-op.cc (frange_mpfr_arg1): New function.
(cfn_sqrt::fold_range): Intersect the generic boundaries range
with range computed from sqrt of the particular bounds.
(cfn_sqrt::op1_range): Intersect the generic boundaries range
with range computed from squared particular bounds.
Jakub Jelinek [Sat, 6 May 2023 00:32:17 +0000 (02:32 +0200)]
build: Replace seq for portability with GNU Make variant
Some hosts like AIX don't have seq command, this patch replaces it
with something that uses just GNU make features we've been using
for this already before for the parallel make check.
2023-05-06 Jakub Jelinek <jakub@redhat.com>
* Makefile.in (check_p_numbers): Rename to one_to_9999, move
earlier with helper variables also renamed.
(MATCH_SPLUT_SEQ): Use $(wordlist 1,$(NUM_MATCH_SPLITS),$(one_to_9999))
instead of $(shell seq 1 $(NUM_MATCH_SPLITS)).
(check_p_subdirs): Use $(one_to_9999) instead of $(check_p_numbers).
Unfortunately, doesn't cause a performance improvement for coremark,
but happens a few times in newlib, just enough to affect coremark
0.01% by size (or 4 bytes, and three cycles (__fwalk_sglue and
__vfiprintf_r each two bytes).
gcc:
* config/cris/cris.md (splitop): Add PLUS.
* config/cris/cris.cc (cris_split_constant): Also handle
PLUS when a split into two insns may be useful.
gcc/testsuite:
* gcc.target/cris/peep2-addsplit1.c: New test.
CRIS: peephole2 a move of constant followed by and of same register
While moves of constants into registers are separately
optimizable, a combination of a move with a subsequent "and"
is slightly preferable even if the move can be generated
with the same number (and timing) of insns, as moves of
"just" registers are eliminated now and then in different
passes, loosely speaking. This movandsplit1 pattern feeds
into the opsplit1/AND peephole2, with matching occurrences
observed in the floating point functions in libgcc. Also, a
test-case to fit. Coremark improvements are unimpressive:
less than 0.0003% speed, 0.1% size.
But that was pre-LRA; after the switch to LRA this peephole2
doesn't match anymore (for any of coremark, local tests,
libgcc and newlib libc) and the test-case passes with and
without the patch. Still, there's no apparent reason why
LRA prefers "move R1,R2" "and I,R2" to "move I,R1" "and
R1,R2", or why that wouldn't "randomly" change (also seen
with other operations than "and"). Thus committed.
gcc:
* config/cris/cris.md (movandsplit1): New define_peephole2.
gcc/testsuite:
* gcc.target/cris/peep2-movandsplit1.c: New test.
Observed after opsplit1 with AND in libgcc floating-point
functions, like the first spottings of opsplit1/AND
opportunities. Two patterns are nominally needed, as the
peephole2 optimizer continues from the *first replacement*
insn, not from a minimum context for general matching; one
that includes it as the last match.
But, the "free-standing" opportunity (three shifts) didn't
match by itself in a gcc build of libraries plus running the
test-suite, and thus deemed uninteresting and left out.
(As expected; if it had matched, that'd have indicated a
previously missed optimization or other problem elsewhere.)
Only the one that includes the previous define_peephole2
that may generate the sequence (i.e. opsplit1/AND), matches
easily.
Coremark results aren't impressive though: 0.003%
improvement in speed and slightly less than 0.1% in size.
A testcase is added to match and another one to cover a case
of movulsr checking that it's used; it's preferable to
lsrandsplit when both would match.
gcc:
* config/cris/cris.md (lsrandsplit1): New define_peephole2.
gcc/testsuite:
* gcc.target/cris/peep2-lsrandsplit1.c,
gcc.target/cris/peep2-movulsr2.c: New tests.
I was a bit surprised when my newly-added define_peephole2 didn't
match, but it was because it was expected to partially match the
generated output of a previous define_peephole2, which matched and
modified the last insn of a sequence to be matched. I had assumed
that the algorithm backed-up the size of the match-buffer, thereby
exposing newly created opportunities *with sufficient context* to all
define_peephole2's. While things can change in that direction, let's
start with documenting the current state.
* doc/md.texi (define_peephole2): Document order of scanning.
Harald Anlauf [Fri, 5 May 2023 19:22:12 +0000 (21:22 +0200)]
Fortran: overloading of intrinsic binary operators [PR109641]
Fortran allows overloading of intrinsic operators also for operands of
numeric intrinsic types. The intrinsic operator versions are used
according to the rules of F2018 table 10.2 and imply type conversion as
long as the operand ranks are conformable. Otherwise no type conversion
shall be performed to allow the resolution of a matching user-defined
operator.
gcc/fortran/ChangeLog:
PR fortran/109641
* arith.cc (eval_intrinsic): Check conformability of ranks of operands
for intrinsic binary operators before performing type conversions.
* gfortran.h (gfc_op_rank_conformable): Add prototype.
* resolve.cc (resolve_operator): Check conformability of ranks of
operands for intrinsic binary operators before performing type
conversions.
(gfc_op_rank_conformable): New helper function to compare ranks of
operands of binary operator.
gcc/testsuite/ChangeLog:
PR fortran/109641
* gfortran.dg/overload_5.f90: New test.
Pan Li [Thu, 4 May 2023 09:11:18 +0000 (17:11 +0800)]
RISC-V: Legitimise the const0_rtx for RVV indexed load/store
This patch try to legitimise the const0_rtx (aka zero register)
as the base register for the RVV indexed load/store instructions
by allowing the const as the operand of the indexed RTL pattern.
Then the underlying combine pass will try to perform the const
propagation.
Before this patch:
li a5,0 <- can be eliminated.
vl1re32.v v1,0(a1)
vsetvli zero,a2,e32,m1,ta,ma
vluxei32.v v1,(a5),v1 <- can propagate the const 0 to a5 here.
vs1r.v v1,0(a0)
ret
After this patch:
test_vluxei32_v_i32m1_shortcut:
vl1re32.v v1,0(a1)
vsetvli zero,a2,e32,m1,ta,ma
vluxei32.v v1,(0),v1
vs1r.v v1,0(a0)
ret
As above, this patch allow you to propagaate the const 0 (aka zero
register) to the base register of the RVV indexed load in the combine
pass. This may benefit the underlying RVV auto-vectorization.
gcc/ChangeLog:
* config/riscv/vector.md: Allow const as the operand of RVV
indexed load/store.
Christophe Lyon [Wed, 8 Feb 2023 21:18:28 +0000 (21:18 +0000)]
arm: [MVE intrinsics] add support for MODE_r
A few intrinsics have an additional mode (MODE_r), which does not
always support the same set of predicates as MODE_none and MODE_n.
For vqshlq they are the same, but for vshlq they are not.
Indeed we have:
vqshlq
vqshlq_m
vqshlq_n
vqshlq_m_n
vqshlq_r
vqshlq_m_r
Juzhe-Zhong [Fri, 5 May 2023 06:33:44 +0000 (14:33 +0800)]
RISC-V: Fix PR109615
This patch is to fix following case:
void f (int8_t * restrict in, int8_t * restrict out, int n, int m, int cond)
{
size_t vl = 101;
if (cond)
vl = m * 2;
else
vl = m * 2 * vl;
for (size_t i = 0; i < n; i++)
{
vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
__riscv_vse8_v_i8mf8 (out + i, v, vl);
vbool64_t mask = __riscv_vlm_v_b64 (in + i + 100, vl);
vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tumu (mask, v, in + i + 100, vl);
__riscv_vse8_v_i8mf8 (out + i + 100, v2, vl);
}
for (size_t i = 0; i < n; i++)
{
vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + 300, vl);
__riscv_vse8_v_i8mf8 (out + i + 300, v, vl);
}
}
The value of "vl" is coming from different blocks so it will be wrapped as a PHI node of each
block.
In the first loop, the "vl" source is a PHI node from bb 4.
In the second loop, the "vl" source is a PHI node from bb 5.
since bb 5 is dominated by bb 4, the PHI input of "vl" in the second loop is the PHI node of "vl"
in bb 4.
So when 2 "vl" PHI node are both degenerate PHI node (the phi->num_inputs () == 1) and their only
input are same, it's safe for us to consider they are compatible.
This patch is only optimize degenerate PHI since it's safe and simple optimization.
non-dengerate PHI are considered as incompatible unless the PHI are the same in RTL_SSA.
TODO: non-generate PHI is complicated, we can support it when it is necessary in the future.
git://gcc.gnu.org / gcc.git / log