> I would guess that getting the store issued as quickly as possible after
> its inputs are resolved is helpful because it usually closes the live
> range from the compiler's standpoint. We've certainly seen that being
> generally useful when looking at scheduler models.
Agreed. That matches my understanding as well.
> from overlap_op_by_pieces. I'd expect the branch cost to be higher to
> encourage the compiler to if-convert aggressively to avoid branch
> mispredictions, but I'm not at all familiar with this core, so I'd go
> with Wang's recommendation here.
I think enabling overlap_op_by_pieces could indeed be beneficial.
But I haven't measured its performance impact, though, so I left it
disabled for now to be conservative.
> I'd be particularly curious if this design is showing that the
> zero-stride-load idiom is meaningfully faster than the alternatives. I
> think that would be the first core where this was true.
Yes, I was informed that we have done the optimization in core.
Best regards,
Yaduo
