diff options
author | Jeff Law <jlaw@ventanamicro.com> | 2025-03-09 13:28:10 -0600 |
---|---|---|
committer | Jeff Law <jlaw@ventanamicro.com> | 2025-03-09 13:31:09 -0600 |
commit | 4ed07a11ee2845c2085a3cd5cff043209a452441 (patch) | |
tree | a906ddd04f2fdfe16c8876b8676dc082f719c46e /libgo/go/time | |
parent | 9f5b508bc5c16ae11ea385f6031487a518f62c8f (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
This is the first of what I expect to be a few patches to improve memory
consumption and performance of ext-dce.
While I haven't been able to reproduce the insane memory usage that Richi saw,
I can certainly see how we might get there. I instrumented ext-dce to dump the
size of liveness sets, removed the memory allocation limiter, then compiled the
appropriate file from specfp on rv64.
In my test I saw the liveness sets growing to absurd sizes as we worked from
the last block back to the first. Think 125k entries by the time we got back
to the entry block which would mean ~30k live registers. Simply no way that's
correct.
The use handling is the primary source of problems and the code that I most
want to rewrite for gcc-16. It's just a fugly mess. I'm not terribly inclined
to do that rewrite for gcc-15 though. So these will be spot adjustments.
The most important thing to know about use processing is it sets up an iterator
and walks that. When a SET is encountered we actually manually
dive into the SRC/DEST and ideally terminate the iterator.
If during that SET processing we encounter something unexpected we let the
iterator continue normally, which causes iteration down into the SET_DEST
object. That's safe behavior, though it can lead to too many objects as being
marked live.
We can refine that behavior by trivially realizing that we need not process the
SET_DEST if it is a naked REG (and probably for other cases too, but they're
not expected to be terribly important). So once we see the SET with a simple
REG destination, we can bump the iterator to avoid having it dive into the
SET_DEST if something unexpected is seen on the SET_SRC side.
Fixing this alone takes us from 125k live objects to 10k live objects at the
entry block. Time in ext-dce for rv64 on the testcase goes from 10.81s to
2.14s.
Given this reduces the things considered live, this could easily result in
finding more cases for ext-dce to improve. In fact a missed optimization issue
for rv64 I've been poking at needs this patch as a prerequisite.
Bootstrapped and regression tested on x86_64.
Pushing to the trunk.
PR rtl-optimization/117467
gcc
* ext-dce.cc (ext_dce_process_uses): When trivially possible advance
the iterator over the destination of a SET.
Diffstat (limited to 'libgo/go/time')
0 files changed, 0 insertions, 0 deletions