All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v3 3/3] or1k: gcc: initial support for openrisc
Date: Sun, 28 Oct 2018 17:54:47 -0500	[thread overview]
Message-ID: <20181028225447.GK5766@gate.crashing.org> (raw)
In-Reply-To: <20181028214723.GD1761@lianli.shorne-pla.net>

Hi!

On Mon, Oct 29, 2018 at 06:47:23AM +0900, Stafford Horne wrote:
> On Sat, Oct 27, 2018 at 09:57:30PM -0500, Segher Boessenkool wrote:
> > > +/* Helper for defining INITIAL_ELIMINATION_OFFSET.
> > > +   We allow the following eliminiations:
> > > +     FP -> HARD_FP or SP
> > > +     AP -> HARD_FP or SP
> > > +
> > > +   HFP and AP are the same which is handled below.  */
> > > +
> > > +HOST_WIDE_INT
> > > +or1k_initial_elimination_offset (int from, int to)
> > 
> > You could calculate this as  some_offset (from) - some_offset (to)  with
> > some_offset a simple helper function.  That gives you all possible
> > eliminations :-)
> > 
> > (Each offset is very cheap to compute in your case, so that's not a problem).
> 
> Right, Do you mean something like the following?  I think it would work, but I
> am not sure it make the code easier to read.  Do you think there would be much
> benefits supporting all possible eliminations?

Yes, like that.  It also easily can handle the other combos (those with
STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWARD
("false" is better on some args, but "true" is required for ssp).

Your code is fine as-is of course.

> > > +#undef TARGET_RTX_COSTS
> > > +#define TARGET_RTX_COSTS or1k_rtx_costs
> > 
> > You may want TARGET_INSN_COST as well (it is easier to get (more) correct).
> 
> OK, I was not considering that for the first port.  Perhaps after getting this
> in?  I think in general the OpenRISC insruction costs are fairly flat for the
> ones are using.

Oh, this was just a suggestion for the future :-)

If you compile with -dp you will see the cost and length for every insn
annotated; are most/all correct?

> > > +   This ABI has no adjacent call-saved register, which means that
> > > +   DImode/DFmode pseudos cannot be call-saved and will always be
> > > +   spilled across calls.  To solve this without changing the ABI,
> > > +   remap the compiler internal register numbers to place the even
> > > +   call-saved registers r16-r30 in 24-31, and the odd call-clobbered
> > > +   registers r17-r31 in 16-23.  */
> > 
> > Ooh evilness :-)
> 
> Richard did this, I thought it was rather clever. :)

Yes!

> > > +#define FUNCTION_ARG_REGNO_P(r) (r >= 3 && r <= 8)
> > 
> > IN_RANGE ?
> 
> OK, I may change it, I think without the macro, its easy to understand that its
> (inclusive).

Yeah, you'll have to remember that IN_RANGE always is inclusive too.  Maybe
if it were used more that woul become second nature to more people :-)


Segher

  reply	other threads:[~2018-10-28 22:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-27  4:36 [OpenRISC] [PATCH v3 0/3] OpenRISC port Stafford Horne
2018-10-27  4:37 ` [OpenRISC] [PATCH v3 1/3] or1k: libgcc: initial support for openrisc Stafford Horne
2018-10-27 23:25   ` Segher Boessenkool
2018-10-28  0:37     ` Stafford Horne
2018-10-28  1:25   ` Richard Henderson
2018-10-29 13:44     ` Stafford Horne
2018-10-27  4:37 ` [OpenRISC] [PATCH v3 2/3] or1k: testsuite: " Stafford Horne
2018-10-28  1:27   ` Richard Henderson
2018-10-27  4:37 ` [OpenRISC] [PATCH v3 3/3] or1k: gcc: " Stafford Horne
2018-10-28  1:56   ` Richard Henderson
2018-10-30 12:18     ` Stafford Horne
2018-10-30 15:57       ` Richard Henderson
2018-10-30 22:44         ` Stafford Horne
2018-10-28  2:57   ` Segher Boessenkool
2018-10-28 21:47     ` Stafford Horne
2018-10-28 22:54       ` Segher Boessenkool [this message]
2018-10-30 12:49         ` Stafford Horne
2018-10-30 15:49           ` Segher Boessenkool
2018-10-30 22:35             ` Stafford Horne
2018-10-31 14:39               ` Jeff Law
2018-10-28 23:16     ` Richard Henderson
2018-10-29 13:34       ` Stafford Horne
2018-10-29 16:34         ` Segher Boessenkool
2018-10-29 16:42           ` Richard Henderson
2018-10-30 11:26             ` Stafford Horne
2018-10-30 15:41               ` Segher Boessenkool
2018-10-29 14:28   ` Szabolcs Nagy
2018-11-04  9:05     ` Stafford Horne
2018-11-05 11:13       ` Szabolcs Nagy
2018-11-05 15:10         ` Rich Felker
2018-11-05 20:58           ` Stafford Horne
2018-11-05 20:52         ` Stafford Horne
2018-11-05 19:45       ` Richard Henderson
2018-11-05 20:14         ` Christophe Lyon
2018-10-28  1:29 ` [OpenRISC] [PATCH v3 0/3] OpenRISC port Richard Henderson

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=20181028225447.GK5766@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=openrisc@lists.librecores.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.