aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorRoger Sayle <roger@nextmovesoftware.com>2023-07-22 21:52:55 +0100
committerRoger Sayle <roger@nextmovesoftware.com>2023-07-22 21:55:25 +0100
commit8125b12f846b41f26e58c0fe3b218d654f65d1c8 (patch)
tree84cb15ee4667b74e2c34a2c85ffd2c4613cc5670 /libgcc
parent659d856e1d424ea8ef634844a7bd08b86ec7344b (diff)
downloadgcc-8125b12f846b41f26e58c0fe3b218d654f65d1c8.zip
gcc-8125b12f846b41f26e58c0fe3b218d654f65d1c8.tar.gz
gcc-8125b12f846b41f26e58c0fe3b218d654f65d1c8.tar.bz2
i386: Don't use insvti_{high,low}part with -O0 (for compile-time).
This patch attempts to help with PR rtl-optimization/110587, a regression of -O0 compile time for the pathological pr28071.c. My recent patch helps a bit, but hasn't returned -O0 compile-time to where it was before my ix86_expand_move changes. The obvious solution/workaround is to guard these new TImode parameter passing optimizations with "&& optimize", so they don't trigger when compiling with -O0. The very minor complication is that "&& optimize" alone leads to the regression of pr110533.c, where our improved TImode parameter passing fixes a wrong-code issue with naked functions, importantly, when compiling with -O0. This should explain the one line fix below "&& (optimize || ix86_function_naked (cfun))". I've an additional fix/tweak or two for this compile-time issue, but this change eliminates the part of the regression that I've caused. 2023-07-22 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * config/i386/i386-expand.cc (ix86_expand_move): Disable the 64-bit insertions into TImode optimizations with -O0, unless the function has the "naked" attribute (for PR target/110533).
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions