https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #62 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
So to summarise this long PR, for my own sanity if nothing else,
the remaining failures are:
FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 0, 8
FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 16, 5
FAIL: gcc.target/aarch64/insv_1.c scan-assembler movk\tx[0-9]+, 0x1d6b, lsl 32
FAIL: gcc.target/aarch64/lsl_asr_sbfiz.c scan-assembler sbfiz\tw
For the two bfi ones: are we really sure that the old code is better?
It's a difference between a MOV and a BFI or an AND and an ORR.
The BFI wins (at least for code-size) if we need the same MOV
for something else. But the AND/ORR sequence wins in high register
pressure, since it only needs one register rather than two.
It could also be better if several changes are being made to the
same structure. We can't really expect to make a good choice
between these in a peephole pass like combine.
So IMO we should just accept the BFI changes for these particular
structures and constants. We can then file a new PR for constant
insertions that can't use ORR.
For the MOVK one, I agree with Segher in comment 42 that this
is just a missing pattern. We should also be using MOVK for:
typedef __UINT64_TYPE__ uint64_t;
uint64_t f (uint64_t x) { return (x & ~(uint64_t) 0xffff0000) | 0x12340000; }
and there's no reason to expect this to be converted into a
zero_extract lhs.
gcc.target/aarch64/lsl_asr_sbfiz.c is IMO due to an overly restrictive
case in simplify-rtx.c, have a patch for that.
