diff options
author | Jakub Jelinek <jakub@redhat.com> | 2023-10-18 12:37:40 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2023-10-18 12:37:40 +0200 |
commit | f1744dd50bb1661c98b694ff907cb0a1be4f6134 (patch) | |
tree | 9dae1063f6f6cd1212120613f46bd57f4e647e4f /gcc/tree-vectorizer.cc | |
parent | d3961765b506f75233e6ea144a80930629c3426b (diff) | |
download | gcc-f1744dd50bb1661c98b694ff907cb0a1be4f6134.zip gcc-f1744dd50bb1661c98b694ff907cb0a1be4f6134.tar.gz gcc-f1744dd50bb1661c98b694ff907cb0a1be4f6134.tar.bz2 |
tree-ssa-math-opts: Fix up match_uaddc_usubc [PR111845]
GCC ICEs on the first testcase. Successful match_uaddc_usubc ends up with
some dead stmts which DCE will remove (hopefully) later all.
The ICE is because one of the dead stmts refers to a freed SSA_NAME.
The code already gsi_removes a couple of stmts in the
/* Remove some statements which can't be kept in the IL because they
use SSA_NAME whose setter is going to be removed too. */
section for the same reason (the reason for the freed SSA_NAMEs is that
we don't really have a replacement for those cases - all we have after
a match is combined overflow from the addition/subtraction of 2 operands + a
[0, 1] carry in, but not the individual overflows from the former 2
additions), but for the last (most significant) limb case, where we try
to match x = op1 + op2 + carry1 + carry2; or
x = op1 - op2 - carry1 - carry2; we just gsi_replace the final stmt, but
left around the 2 temporary stmts as dead; if we were unlucky enough that
those referenced the carry flag that went away, it ICEs.
So, the following patch remembers those temporary statements (rather than
trying to rediscover them more expensively) and removes them before the
final one is replaced.
While working on it, I've noticed we didn't support all the reassociated
possibilities of writing the addition of 4 operands or subtracting 3
operands from one, we supported e.g.
x = ((op1 + op2) + op3) + op4;
x = op1 + ((op2 + op3) + op4);
but not
x = (op1 + (op2 + op3)) + op4;
x = op1 + (op2 + (op3 + op4));
Fixed by the change to inspect also rhs[2] when rhs[1] didn't yield what
we were searching for (if non-NULL) - rhs[0] is inspected in the first
loop and has different handling for the MINUS_EXPR case.
2023-10-18 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/111845
* tree-ssa-math-opts.cc (match_uaddc_usubc): Remember temporary
statements for the 4 operand addition or subtraction of 3 operands
from 1 operand cases and remove them when successful. Look for
nested additions even from rhs[2], not just rhs[1].
* gcc.dg/pr111845.c: New test.
* gcc.target/i386/pr111845.c: New test.
Diffstat (limited to 'gcc/tree-vectorizer.cc')
0 files changed, 0 insertions, 0 deletions