diff options
author | Jeff Law <jlaw@ventanamicro.com> | 2024-11-17 16:44:09 -0700 |
---|---|---|
committer | Jeff Law <jlaw@ventanamicro.com> | 2024-11-17 21:44:50 -0700 |
commit | beec291225be9b5e7a60b6818cf80224c343811d (patch) | |
tree | e1c934143a0a6708fa3927227e532317eebee1b7 /maintainer-scripts/gcc_release | |
parent | 4a8eb5c6d87f3a1ccdf6eb248e6a7dd4cffbb7d4 (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
I was looking at a regression in ext-dce's behavior just before Cauldron.
Essentially a bugfix in ext-dce ended up causing us to fail to eliminate some
useless extensions.
When we have a SUBREG object with SUBREG_PROMOTED_VAR* flags set, we generally
have to be more conservative in how we process bit group liveness, making bits
live that wouldn't obviously be live otherwise.
That's not always necessary though. For example, if we're storing a promoted
subreg into memory, we may not care about those extra live bits on this
instance of the subreg object (remember subregs are not shared!). Essentially
if the mode of the memory reference is not wider than the mode of the inner
REG, then we can clear the promoted state which in turn may allow more
extension elimination.
So at the start of ext-dce we do a simple pass over the IL and remove promoted
subreg state when it's obviously safe to do so (memory stores when the modes
allow it). That prevents extra bits from being live and ultimately allows us
to remove more useless extensions.
The testcase is in theory generic, but many targets won't have an opportunity
to optimize this case. So rather then build out a large inclusion/exclusion
list, I've just made the test risc-v specific.
Bootstrapped and regression tested on aarch64, riscv64, s390x, etc in my tester.
gcc/
* ext-dce.cc (maybe_clear_subreg_promoted_p): New function.
(ext_dce_execute): Call it.
gcc/testsuite
* gcc.target/riscv/ext-dce-1.c: New test.
Diffstat (limited to 'maintainer-scripts/gcc_release')
0 files changed, 0 insertions, 0 deletions