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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox