diff options
author | Roger Sayle <roger@nextmovesoftware.com> | 2023-07-12 14:14:15 +0100 |
---|---|---|
committer | Roger Sayle <roger@nextmovesoftware.com> | 2023-07-12 14:14:15 +0100 |
commit | 275a2124e4928c88bd5469096356ba393b6aadfb (patch) | |
tree | aa4790850e7970c3df7ea42115eec85a4f5d3528 /gcc/tree-ssa-loop-ch.cc | |
parent | d2c18b4a16f9e1a6ed271ec1efaf94533d1c4a94 (diff) | |
download | gcc-275a2124e4928c88bd5469096356ba393b6aadfb.zip gcc-275a2124e4928c88bd5469096356ba393b6aadfb.tar.gz gcc-275a2124e4928c88bd5469096356ba393b6aadfb.tar.bz2 |
i386: Fix FAIL of gcc.target/i386/pr91681-1.c
The recent change in TImode parameter passing on x86_64 results in the
FAIL of pr91681-1.c. The issue is that with the extra flexibility,
the combine pass is now spoilt for choice between using either the
*add<dwi>3_doubleword_concat or the *add<dwi>3_doubleword_zext
patterns, when one operand is a *concat and the other is a zero_extend.
The solution proposed below is provide an *add<dwi>3_doubleword_concat_zext
define_insn_and_split, that can benefit both from the register allocation
of *concat, and still avoid the xor normally required by zero extension.
I'm investigating a follow-up refinement to improve register allocation
further by avoiding the early clobber in the =&r, and handling (custom)
reloads explicitly, but this piece resolves the testcase failure.
2023-07-12 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/91681
* config/i386/i386.md (*add<dwi>3_doubleword_concat_zext): New
define_insn_and_split derived from *add<dwi>3_doubleword_concat
and *add<dwi>3_doubleword_zext.
Diffstat (limited to 'gcc/tree-ssa-loop-ch.cc')
0 files changed, 0 insertions, 0 deletions