Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: Jeremy Singher <thejsingher@gmail.com>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] Introduction and Questions
Date: Sat, 16 May 2020 13:34:14 -0700
Message-ID: <CAEoCstQLUzbeAyBBWE_FH8=AD78nd-qG8eAJo_cXaTG_Wz4ysQ@mail.gmail.com> (raw)
In-Reply-To: <7c84f530-fc12-0f4e-8a1c-7e58a1b498c3@fibraservi.eu>

> 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@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@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

  parent reply index

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 18:24 Jeremy Singher
2020-05-15 18:45 ` Yehowshua
2020-05-15 19:15   ` Jeremy Singher
2020-05-15 19:20     ` Yehowshua
2020-05-15 19:24     ` Yehowshua
2020-05-15 19:33     ` Yehowshua
2020-05-15 20:11       ` Luke Kenneth Casson Leighton
2020-05-15 20:50         ` Jeremy Singher
2020-05-15 21:03           ` Yehowshua
2020-05-15 21:19           ` Jacob Lifshay
2020-05-15 21:55             ` Luke Kenneth Casson Leighton
2020-05-15 21:53           ` Luke Kenneth Casson Leighton
2020-05-15 22:15             ` Jeremy Singher
2020-05-15 22:29               ` Yehowshua
2020-05-15 22:51                 ` Luke Kenneth Casson Leighton
2020-05-15 22:47               ` Luke Kenneth Casson Leighton
2020-05-15 23:49                 ` Jeremy Singher
2020-05-16  0:40                   ` Luke Kenneth Casson Leighton
2020-05-16  9:47                   ` Staf Verhaegen
2020-05-16 11:30                     ` Staf Verhaegen
2020-05-16 12:30                       ` Luke Kenneth Casson Leighton
2020-05-16 20:34                       ` Jeremy Singher [this message]
2020-05-16 21:42                         ` Luke Kenneth Casson Leighton
2020-05-16  9:43       ` Staf Verhaegen
2020-05-16 12:14         ` Luke Kenneth Casson Leighton
2020-05-15 18:47 ` Yehowshua
2020-05-16 12:11 ` Luke Kenneth Casson Leighton
  -- strict thread matches above, loose matches on Subject: below --
2020-05-15  6:50 Jeremy Singher
2020-06-06 22:47 ` Yehowshua
2020-06-06 22:48   ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEoCstQLUzbeAyBBWE_FH8=AD78nd-qG8eAJo_cXaTG_Wz4ysQ@mail.gmail.com' \
    --to=thejsingher@gmail.com \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git