diff options
author | Luis Machado <luis.machado@linaro.org> | 2018-05-22 18:35:15 +0000 |
---|---|---|
committer | Luis Machado <luisgpm@gcc.gnu.org> | 2018-05-22 18:35:15 +0000 |
commit | 58c2ad42a89438281327c74afb3f7483ffe22514 (patch) | |
tree | e5383edb41763183c8360ddf1bcd8410ebdf25db /gcc/builtins.c | |
parent | 927a00917dfdf5585159803211c71910b32da10f (diff) | |
download | gcc-58c2ad42a89438281327c74afb3f7483ffe22514.zip gcc-58c2ad42a89438281327c74afb3f7483ffe22514.tar.gz gcc-58c2ad42a89438281327c74afb3f7483ffe22514.tar.bz2 |
[AArch64] Recognize a missed usage of a sbfiz instruction
A customer reported the following missed opportunities to combine a couple
instructions into a sbfiz.
int sbfiz32 (int x)
{
return x << 29 >> 10;
}
long sbfiz64 (long x)
{
return x << 58 >> 20;
}
This gets converted to the following pattern:
(set (reg:SI 98)
(ashift:SI (sign_extend:SI (reg:HI 0 x0 [ xD.3334 ]))
(const_int 6 [0x6])))
Currently, gcc generates the following:
sbfiz32:
lsl x0, x0, 29
asr x0, x0, 10
ret
sbfiz64:
lsl x0, x0, 58
asr x0, x0, 20
ret
It could generate this instead:
sbfiz32:
sbfiz w0, w0, 19, 3
ret
sbfiz64::
sbfiz x0, x0, 38, 6
ret
The unsigned versions already generate ubfiz for the same code, so the lack of
a sbfiz pattern may have been an oversight.
This particular sbfiz pattern shows up in both CPU2006 (~ 80 hits) and
CPU2017 (~ 280 hits). It's not a lot, but seems beneficial in any case. No
significant performance differences, probably due to the small number of
occurrences or cases outside hot areas.
gcc/ChangeLog:
2018-05-22 Luis Machado <luis.machado@linaro.org>
gcc/
* config/aarch64/aarch64.md (*ashift<mode>_extv_bfiz): New pattern.
gcc/testsuite/ChangeLog:
2018-05-22 Luis Machado <luis.machado@linaro.org>
gcc/testsuite/
* gcc.target/aarch64/lsl_asr_sbfiz.c: New test.
From-SVN: r260546
Diffstat (limited to 'gcc/builtins.c')
0 files changed, 0 insertions, 0 deletions