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: Sat, 27 Oct 2018 21:57:30 -0500	[thread overview]
Message-ID: <20181028025730.GH5766@gate.crashing.org> (raw)
In-Reply-To: <20181027043702.18414-4-shorne@gmail.com>

Hi Stafford,

Some minor comments.  I didn't read the atomics much, but I did look at
everything else, and it looks fine :-)

On Sat, Oct 27, 2018 at 01:37:02PM +0900, Stafford Horne wrote:
> +        case ${target} in
> +        or1k*-*-linux*)
> +                tm_file="${tm_file} gnu-user.h linux.h glibc-stdint.h"
> +                tm_file="${tm_file} or1k/linux.h"
> +                ;;

Spaces instead of tabs.

> +  /* Number of bytes saved on the stack for outgoing/sub-fucntion args.  */

Typo ("function").

> +  /* The sum of sizes: locals vars, called saved regs, stack pointer
> +   * and an optional frame pointer.
> +   * Used in expand_prologue () and expand_epilogue().  */

We don't use leading stars in comments (just spaces), normally.

> +  /* Set address to volitile to ensure the store doesn't get optimized out.  */

"volatile"


> +/* 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).

> +static rtx
> +or1k_function_value (const_tree valtype,
> +		     const_tree fn_decl_or_type ATTRIBUTE_UNUSED,
> +		     bool outgoing ATTRIBUTE_UNUSED)

Since we use C++ now you can write this as
		     bool /*outgoing*/)
or such, for enhanced readability.

> +   split.  Symbols are lagitimized using split relocations.  */

"legitimized"

> +void
> +or1k_expand_move (machine_mode mode, rtx op0, rtx op1)
> +{
> +  if (MEM_P (op0))
> +    {
> +      if (!const0_operand(op1, mode))

Space before (.

> +#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).

> +      if (hi != 0)
> +	{
> +	  rtx scratch2 = gen_rtx_REG (Pmode, RV_REGNUM);
> +	  emit_move_insn (scratch2, GEN_INT (hi));
> +	  emit_insn (gen_add2_insn (scratch, scratch2));
> +        }

Tab instead of spaces.

> +  /* Generate a tail call to the target function.  */
> +  if (! TREE_USED (function))

No space after !.

> +#define TARGET_RETURN_IN_MEMORY	or1k_return_in_memory

> +#define	TARGET_PASS_BY_REFERENCE or1k_pass_by_reference

These two have a tab instead of a space (as the rest do).

> +#define WCHAR_TYPE_SIZE	32

And this.

> +   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 :-)

> +#define Pmode	SImode
> +#define FUNCTION_MODE	SImode

Some more tabs.

> +#define FUNCTION_ARG_REGNO_P(r) (r >= 3 && r <= 8)

IN_RANGE ?

> + { ARG_POINTER_REGNUM,	 STACK_POINTER_REGNUM },	\

Weird tab here, too.

> +#define EH_RETURN_REGNUM	HW_TO_GCC_REGNO (23)

And here.

> +(define_insn "xorsi3"
> +  [(set (match_operand:SI 0 "register_operand" "=r,r")
> +	  (xor:SI
> +	   (match_operand:SI 1 "register_operand"   "%r,r")
> +	   (match_operand:SI 2 "reg_or_s16_operand" " r,I")))]
> +  ""
> +  "@
> +  l.xor\t%0, %1, %2
> +  l.xori\t%0, %1, %2")

Is this correct?  Should this be unsigned (u16 and K)?
https://sourceware.org/cgen/gen-doc/openrisc-insn.html suggest so, but I
don't know how up-to-date or relevant that is.  Well.  From the atomics
much below it seems to be correct, and signed is nice for making a bit
inverse.  Is there some better documentation?  Something to put at
https://gcc.gnu.org/readings.html (this is in the CVS repo, still see
https://gcc.gnu.org/about.html#cvs ).

> +(define_expand "mov<I:mode>"
> +  [(set (match_operand:I 0 "nonimmediate_operand" "")
> +	(match_operand:I 1 "general_operand" ""))]

You can completely leave out empty constraint strings, for example in the
expanders.

> +mhard-div
> +Target RejectNegative InverseMask(SOFT_DIV)
> +Use hardware divide instructions, use -msoft-div for emulation.
> +
> +mhard-mul
> +Target RejectNegative InverseMask(SOFT_MUL).
> +Use hardware multiply instructions, use -msoft-mul for emulation.

Maybe put the -msoft-* options near here then?


This was a lovely read.  Thank you!  Your port looks great.


Segher

  parent reply	other threads:[~2018-10-28  2:57 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 [this message]
2018-10-28 21:47     ` Stafford Horne
2018-10-28 22:54       ` Segher Boessenkool
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=20181028025730.GH5766@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.