[libre-riscv-dev] Introduction and Questions

Jeremy Singher thejsingher at gmail.com
Sat May 16 21:34:14 BST 2020


> Ok after some reflection I do see the most possible performance
> difference in procedures calls. Most of the time in procedures some
> scratch registers are pushed on the stack at entering.

Its actually a performance difference on more cases than this. In the
case of W R W R sequence to the same register, the second Write should
be allowed to proceed before the first Write is executed, which also
unblocks the second R.


On Sat, May 16, 2020 at 4:31 AM Staf Verhaegen <staf at fibraservi.eu> wrote:
>
>
> Op 16/05/2020 om 11:47 schreef Staf Verhaegen:
> > Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
> >>
> >> Hmmm, ignoring WAW will significantly limit the ability of the core to
> >> exploit ILP, which is one of the fundamental reasons for going OOO.
> > I've wondered about this myself. Can you give concrete example of where
> > not supporting a WAW hazard blocks ILP ?
> > I am asking because just a WAW hazard could be easily avoided by a good
> > peep hole optimizer in software because it would see that the output of
> > the first write is never used.
>
> Ok after some reflection I do see the most possible performance
> difference in procedures calls. Most of the time in procedures some
> scratch registers are pushed on the stack at entering.
>
> Assume a write to a scratch register is still pending when doing a
> procedure. With real register renaming the register stack push does not
> need to block until write to register is complete, if it doesn't the
> register push will block.
>
> The question is special hardware provision need to be done to optimize
> this case or if one would rely on proper inlining of functions by the
> compiler for performance critical code. Personally I don't see a problem
> with relying on the latter.
>
> greets,
> Staf.
>
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev



More information about the libre-riscv-dev mailing list