Skip to content

Add Predictor Latency + Refactor cond pred out of BPredUnit#7

Open
shadowcpy wants to merge 3 commits intofdp-developfrom
bpu-cond-refactor
Open

Add Predictor Latency + Refactor cond pred out of BPredUnit#7
shadowcpy wants to merge 3 commits intofdp-developfrom
bpu-cond-refactor

Conversation

@shadowcpy
Copy link
Copy Markdown
Collaborator

This PR introduces the following changes:

  • Fix a memory leak in the FDP packet processing logic (by @dhschall), supersedes cpu: fix bac memory leak (by @dhschall) #6
  • Add latency modeling to the BAC stage, configurable with the new bacBranchPredictDelay param in the O3 CPU
  • Split out the conditional branch predictor from BPredUnit into its own ConditionalPredictor, and update all predictor implementations to derive from the new class instead

Migration process for config scripts

To adapt the changes in your configuration, change code that looks like this:

class BPTageSCL(TAGE_SC_L_64KB):
    indirectBranchPred = ITTAGE()
    # ... other attributes

to this:

class BPTageSCL(BranchPredictor):
    indirectBranchPred = ITTAGE()
    conditionalBranchPred = TAGE_SC_L_64KB()
    # ... other attributes

dhschall pushed a commit that referenced this pull request Mar 26, 2026
Static storage duration objects that has non-trivial destructor are bad.
And a function-local static reference of the form static T& t = *new T;
is allowed
Reference for the style guide:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables

Background:
There's a segmentation fault on the arm server if I run the gem5
simulation with --dry-run, do m5.instantiation() but no m5.simulation().

Stack trace:
Thread 1 "gem5.opt" received signal SIGSEGV, Segmentation fault.
__GI_strcmp () at ../sysdeps/aarch64/strcmp.S:136
warning: 136    ../sysdeps/aarch64/strcmp.S: No such file or directory
(gdb) bt
#0  __GI_strcmp () at ../sysdeps/aarch64/strcmp.S:136
#1 0x0000aaaab415f424 in sc_gem5::(anonymous namespace)::findEventIn
(events=std::vector of length 2, capacity 2 = {...}, name="event_0") at
/usr/include/c++/14/bits/basic_string.h:227
#2 sc_gem5::(anonymous namespace)::popEvent (events=0xaaaac00aed50
<sc_gem5::topLevelEvents()::topLevelEvents>, name="event_0") at
src/systemc/core/event.cc:68
#3 sc_gem5::Event::~Event (this=0xaaaac1d8b000, __in_chrg=<optimized
out>) at src/systemc/core/event.cc:150
#4 0x0000aaaab417e95c in sc_core::sc_event::~sc_event (this=<optimized
out>, __in_chrg=<optimized out>) at src/systemc/core/sc_event.cc:321
#5  0x0000aaaabf7b39e0 in scx::async_request::~async_request() ()
#6 0x0000aaaabf7b12d4 in scx::scheduler_mapping::~scheduler_mapping() ()
#7 0x0000aaaabf7b1498 in scx::scheduler_mapping::~scheduler_mapping() ()
#8 0x0000aaaabf7adfb4 in scx::scx_simcontroller::~scx_simcontroller() ()
#9 0x0000ffffe7b5946c in __run_exit_handlers (status=0,
listp=0xffffe7cd0660 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:118
#10 0x0000ffffe7b59560 [PAC] in __GI_exit (status=<optimized out>) at
./stdlib/exit.c:148
#11 0x0000ffffe7b42220 [PAC] in __libc_start_call_main
(main=main@entry=0xaaaab6af43a0 <main(int, char**)>, argc=argc@entry=15,
argv=argv@entry=0xffffffffeee8) at
../sysdeps/nptl/libc_start_call_main.h:74
#12 0x0000ffffe7b422fc [PAC] in __libc_start_main_impl
(main=0xaaaab6af43a0 <main(int, char**)>, argc=15, argv=0xffffffffeee8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=<optimized out>) at ../csu/libc-start.c:360
gem5#13 0x0000aaaab4003b30 [PAC] in _start ()

The issue seems to be the destruction order. There's a static
topLevelEvents() that will be used in Event() ctor with sc_event. The
segmentation fault happens when topLevelEvents already be destruct
before ~Event calling destructor that will use topLevelEvents.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant