summaryrefslogtreecommitdiff
path: root/config/stdint.m4
diff options
context:
space:
mode:
authorRoger Sayle <roger@nextmovesoftware.com>2020-08-16 19:20:27 +0100
committerGiuliano Belinassi <giuliano.belinassi@usp.br>2020-08-17 15:08:16 -0300
commit114c0f9c0a364641bcdc608879236c418ae9837d (patch)
tree19e5135313e10f3b513a6ef4d944ecb9346e4199 /config/stdint.m4
parent1603043d391f82fe92c65fe76232f64cb4dc5d84 (diff)
downloadgcc-114c0f9c0a364641bcdc608879236c418ae9837d.tar.gz
middle-end: Simplify (sign_extend:HI (truncate:QI (ashiftrt:HI X 8)))
The combination of several my recent nvptx patches has revealed an interesting RTL optimization opportunity. This patch to simplify-rtx.c simplifies (sign_extend:HI (truncate:QI (?shiftrt:HI x 8))) to just (ashiftrt:HI x 8), as the inner shift already sets the high bits appropriately. The equivalent zero_extend variant appears to already be implemented in simplify_unary_operation_1. These result from RTL expansion generating a reasonable arithmetic right shift and truncation to char, only to then discover the backend doesn't support QImode comparisons, so the next optab widens this result/operand back to HImode. In this sequence the truncate and sign extend are redundant as the original arithmetic shift has already set the high bits appropriately. The one oddity of the patch is that it tests for LSHIFTRT as inner shift, as simplify/combine has already canonicalized this to a logical shift, assuming that the distinction is unimportant following the truncatation. 2020-08-16 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * simplify-rtx.c (simplify_unary_operation_1) [SIGN_EXTEND]: Simplify (sign_extend:M (truncate:N (lshiftrt:M x C))) to (ashiftrt:M x C) when the shift sets the high bits appropriately.
Diffstat (limited to 'config/stdint.m4')
0 files changed, 0 insertions, 0 deletions