aboutsummaryrefslogtreecommitdiff
path: root/libjava/classpath/gnu/java/security
diff options
context:
space:
mode:
authorHans-Peter Nilsson <hp@axis.com>2026-02-09 21:34:10 +0100
committerHans-Peter Nilsson <hp@gcc.gnu.org>2026-02-12 19:34:11 +0100
commite4c21d8485467d58a89c82829025c86cb3154a4b (patch)
tree8da5a33af85e9c7cd53f0ab085087a399c58cb41 /libjava/classpath/gnu/java/security
parent6fdd184731aadb2d6cf5afa866ec9eb63126516a (diff)
downloadgcc-e4c21d8485467d58a89c82829025c86cb3154a4b.zip
gcc-e4c21d8485467d58a89c82829025c86cb3154a4b.tar.gz
gcc-e4c21d8485467d58a89c82829025c86cb3154a4b.tar.bz2
CRIS: Make sure cstore<mode>4, cbranch<mode>4 don't have two memory operands
Yet more testing showed that compare insns too, were prone to catching double-memory operands, for example with c-c++-common/vector-compare-3.c -O2, from gcc.dg. So, better try to fix them, helping current and future optimization passes that are reluctant or unable to operate on patterns with two memory operands. This just happens at expansion time by hacking the force_reg stuff to conveniently happen in the operand-massaging function cris_reduce_compare. Together, this and the two previous CRIS patches did improve coremark results, but by a miniscule factor: speed by 0.002% (from 4887074 to 4886993 cycles) and size by 0.1% (code from 58199 to 58143 bytes) and as you can see, with rounding doing heavy lifting. * config/cris/cris.cc (cris_reduce_compare): Add forcing the first operand to be a register, unless the second operand is 0, to scope. * config/cris/cris.md ("*cstore<mode><code>4") ("*cbranch<mode><code>4"): Add guards to condition, for either operand to be a register unless the last operand is zero.
Diffstat (limited to 'libjava/classpath/gnu/java/security')
0 files changed, 0 insertions, 0 deletions