public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Re: best ABI strategy ?
Date: Wed, 30 Nov 2011 21:18:00 -0000	[thread overview]
Message-ID: <CAJ-J9_WqN6ShhPXSMHJ+AX3DfTU61STy_9HWVvAcNk6dJK5PZg@mail.gmail.com> (raw)
In-Reply-To: <4ED5FA7C.8080209@gjlay.de>

2011/11/30 Georg-Johann Lay <avr@gjlay.de>:
> Aurelien Buhrig wrote:
>> Hi,
>>
>> I'm trying to optimize our target ABI, and I'm wondering what is the
>> best strategy to define it.
>> Is there a paper, or any hint, dealing with this topic ?
>> For instance,
>> - which ratio between call-used-reg vs "static regs"
>> - which ratio between arg regs vs call-used-reg
>> - what should be return regs
>> - ...
>> I guess this problem is very target dependent, but there are maybe
>> general ideas about this.
>
> If it's about new hardware/silicon/controller, it is a good idea to do a
> controller compiler co-design. That way you can get the best out of a new
> architecture as you have the most degrees of freedom to find a good point in
> the ISA/ABI plane.
>
> This requires of course to start the compiler development early and in a stage
> where the ISA is still work in progress, i.e. there is no final silicon but
> just an instruction set simulator for the upcoming hardware.
>
> In many cases, you cannot really say what's the best except you actually
> implement it and look how smooth it works.  My experience is that ISA designers
> just think up to the assembler level, but have no idea how a compiler works and
> what it needs and which features it can use and which not.
>
> If the silicon/ISA is already fix and there is no feedback possible, it is
> often easy to parametrize different ABI flavours through compiler switches so
> you can benchmark, switch back and forth between ABIs and see what their pros
> and contras are.
>
> Johann

Hi Johann,

We actually tried to optimize both the ISA and the compîler for the
new extended version, although there was some legacy. Now ISA is
almost fixed. I'm just trying to see which register convention is the
best. I will try to use/define those switches to benchmak the ABI, but
I wanted to know if such studies were available.

Thanks for your reply,
Aurélien

  reply	other threads:[~2011-11-30 14:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30 16:18 Aurelien Buhrig
2011-11-30 16:57 ` Georg-Johann Lay
2011-11-30 21:18   ` Aurelien Buhrig [this message]
2011-11-30 18:49 ` Aurelien Buhrig
     [not found] ` <mcrfwh5saxu.fsf@dhcp-172-18-216-180.mtv.corp.google.com>
2011-12-01 13:09   ` Aurelien Buhrig

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=CAJ-J9_WqN6ShhPXSMHJ+AX3DfTU61STy_9HWVvAcNk6dJK5PZg@mail.gmail.com \
    --to=aurelien.buhrig.gcc@gmail.com \
    --cc=gcc-help@gcc.gnu.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).