Guard pipelined_simd_unit against initiation_interval > latency

[AndrewVu23]

Summary

Prevents a memory-corrupting out-of-bounds access when a functional unit is configured with initiation_interval > latency. Turns a wild SIGSEGV into a bounded first-stage placement.

Motivation / root cause

After adding gpgpusim.config & trace.config and running the sim for RTX 3060, the tests for FP64 failed. I digged deeper into the trace.config and saw this:

Those 2 numbers in -trace_opcode_latency_initiation_dp retrun their values to latency and initiation_interval in shader.cc

With start_stage (or index) at -9, the run crashes.

Changes

• shader.cc: if (start_stage < 0) start_stage = 0; before the pipeline-reg access

Limitations / known gaps

• This is just a guard, not a full fix. With init > latency the run instead hits a register_set: No free registers assertion, which is not handled by the sim. In order to pass segfault while running FP64, I had to change the values manually (make them equal). Also, after further checking, RTX 2060 & 3070 configs in the sim also has 64, 64 (just like mine after manually fixing).
• I don't know if that bug is produced by running the sim through WSL or not, but I have been having a lot of issues with using WSL lately. I think it's worth looking into that.
• I don't have the clean fix for this bug yet, but I may propose that we size the pipeline & reg sets to max(latency, init)

[AndrewVu23]

Just went through the issues and apparently, I'm not the only one who has this problem:

accel-sim/gpu-app-collection#75 (comment)
accel-sim/gpu-app-collection#75 (comment)
accel-sim/accel-sim-framework#505 (comment)