public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Paul Koning <paulkoning@comcast.net>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Turn on LRA on all targets
Date: Fri, 16 Feb 2024 14:23:54 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2402161359210.3971@angie.orcam.me.uk> (raw)
In-Reply-To: <20240216134748.GF19790@gate.crashing.org>

On Fri, 16 Feb 2024, Segher Boessenkool wrote:

> >  Conversely no heuristics is required to unwind VAX frames, because they 
> > are fixed in layout by hardware, fully self-described, and with the 
> > hardware frame pointer always available.
> 
> The downside of the VAX situation of course is that the compiler has no
> freedom to optimise the frame and *logue code at all, let alone well.
> This may not matter so much on narrow ucoded in-order machines, there
> are different balances there :-)

 There is no function prologue to optimise in the VAX case, because all 
the frame setup has already been made by the CALLS instruction itself in 
the caller.  The first machine instruction of the callee is technically 
already past the "prologue".  And then RET serves as the whole function 
"epilogue".

 A discussion happened at the VAX/NetBSD mailing list as to a change to 
the calling convention to make it more RISC-like and replace the procedure 
call (CALLS and CALLG; the latter unused in our psABI) and return (RET) 
instructions with the subroutine branch (BSB), jump (JSB) and return (RSB) 
instructions, which are similar in semantics to say x86 CALL (for BSB/JSB) 
and RET (for RSB) instructions.  Should that happen we'd have fine-grained 
control over the function prologues and epilogues.

 It's not clear however what the consequences such a change would have on 
performance, and it would surely increase code size.  And the final VAX 
microarchitecture implementations (NVAX/NVAX+, dating back to 1991) have 
provisions in hardware, unsurprisingly, for optimising the execution speed 
of the CALL* and RET instructions.

  Maciej

  reply	other threads:[~2024-02-16 14:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-23 16:47 Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
2023-04-23 20:23   ` Segher Boessenkool
2023-04-24  8:42   ` Andreas Schwab
2023-04-23 18:36 ` Paul Koning
2023-04-23 20:19   ` Segher Boessenkool
2023-04-23 18:56 ` Maciej W. Rozycki
2023-04-23 20:33   ` Segher Boessenkool
2023-05-15 21:09     ` Maciej W. Rozycki
2023-05-15 21:16       ` Sam James
2024-02-15 19:34         ` Sam James
2024-02-15 22:56           ` Segher Boessenkool
2024-02-16  1:41             ` Paul Koning
2024-02-16 10:22               ` Segher Boessenkool
2024-02-15 22:21       ` Paul Koning
2024-02-16 11:34         ` Maciej W. Rozycki
2024-02-16 13:47           ` Segher Boessenkool
2024-02-16 14:23             ` Maciej W. Rozycki [this message]
2024-02-16 14:31               ` Jakub Jelinek
2024-02-16 17:01                 ` Maciej W. Rozycki
2024-02-17  0:38                   ` Maciej W. Rozycki
2024-02-16 14:50           ` Paul Koning
2023-04-23 21:06 ` Uros Bizjak
2023-04-24  9:17   ` Segher Boessenkool
2023-04-24  9:46     ` Uros Bizjak
2023-04-29 14:38       ` Segher Boessenkool
2023-04-24  8:19 ` Richard Biener
2023-04-24  9:44   ` Segher Boessenkool
2023-04-30 19:52 ` Jeff Law
2023-04-29 13:37 Roger Sayle
2023-04-29 15:06 ` Jeff Law

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=alpine.DEB.2.21.2402161359210.3971@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=paulkoning@comcast.net \
    --cc=segher@kernel.crashing.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).