Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Mon, Nov 05, 2018 at 10:10:22AM -0500, Rich Felker wrote:
> On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> > On 04/11/18 09:05, Stafford Horne wrote:
> > > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> > >> On 27/10/18 05:37, Stafford Horne wrote:
> > ...
> > >>> +#undef LINK_SPEC
> > >>> +#define LINK_SPEC "%{h*}   \
> > >>> +   %{static:-Bstatic}  \
> > >>> +   %{shared:-shared}   \
> > >>> +   %{symbolic:-Bsymbolic}  \
> > >>> +   %{!static:  \
> > >>> + %{rdynamic:-export-dynamic}   \
> > >>> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> > >>> +
> > >>> +#endif /* GCC_OR1K_LINUX_H */
> > >>
> > >> note that because of the -static-pie mess each
> > >> target needs a more complicated LINK_SPEC now.
> > > 
> > > Hello,
> > > 
> > > Does something like this look better?
> > > 
> > > --- a/gcc/config/or1k/linux.h
> > > +++ b/gcc/config/or1k/linux.h
> > > @@ -37,8 +37,9 @@
> > > %{static:-Bstatic}  \
> > > %{shared:-shared}   \
> > > %{symbolic:-Bsymbolic}  \
> > > -   %{!static:  \
> > > +   %{!static:%{!static-pie:\
> > >   %{rdynamic:-export-dynamic}   \
> > > - %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> > > + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
> > > +   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
> > >  
> > >  #endif /* GCC_OR1K_LINUX_H */
> > 
> > looks ok.
> > 
> > > I have tested this out with or1k-linux-musl, but I get some LD complaints 
> > > i.e.
> > > 
> > > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): 
> > > non-pic relocation against symbol __fini_array_end
> > > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): 
> > > non-pic relocation against symbol __fini_array_start
> > > 
> > > Those are some warnings we recently added to LD, perhaps I need to 
> > > rebuild the
> > > libc.a with PIE as well.  I will try it out, but if anyone has some 
> > > suggestions
> > > that would be helpful.
> > 
> > yes, musl does not build libc.a with pic by default,
> > either use a gcc configured with --enable-default-pie
> > or CC='gcc -fPIC' when building musl.
> > 
> > after that -static-pie linking should work.
> > 
> > (maybe musl should have an --enable-static-pie config
> > option to make this simpler)
> 
> For practical purposes, if you want to use static pie, you need a
> default-pie toolchain. This is because _every_ static lib you might
> link needs to be built with -fPIE (or -fPIC), and ensuring that
> happens on a package-by-package basis is largely impractical; at least
> it's on the same order of magnitude of difficulty as other systems
> integration/packaging tasks.

Thanks, I kind of figured it out, but it was no so clear when I started.

> However from the musl side it might make sense to produce a libc_pic.a
> as part of the build process. This would make it easy to replace
> libc.a with libc_pic.a if desired, and could also be used as the basis
> for linking libc.so and to allow production of a stripped-down libc.so
> that only includes symbols a fixed set of binaries depend on. We could
> discuss something like this on the musl list.

That makes sense.

Thanks Rich for your input.

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_SPEC
> >>> +#define LINK_SPEC "%{h*} \
> >>> +   %{static:-Bstatic}\
> >>> +   %{shared:-shared} \
> >>> +   %{symbolic:-Bsymbolic}\
> >>> +   %{!static:\
> >>> + %{rdynamic:-export-dynamic} \
> >>> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> >>> +
> >>> +#endif /* GCC_OR1K_LINUX_H */
> >>
> >> note that because of the -static-pie mess each
> >> target needs a more complicated LINK_SPEC now.
> > 
> > Hello,
> > 
> > Does something like this look better?
> > 
> > --- a/gcc/config/or1k/linux.h
> > +++ b/gcc/config/or1k/linux.h
> > @@ -37,8 +37,9 @@
> > %{static:-Bstatic}  \
> > %{shared:-shared}   \
> > %{symbolic:-Bsymbolic}  \
> > -   %{!static:  \
> > +   %{!static:%{!static-pie:\
> >   %{rdynamic:-export-dynamic}   \
> > - %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> > + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
> > +   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
> >  
> >  #endif /* GCC_OR1K_LINUX_H */
> 
> looks ok.
> 
> > I have tested this out with or1k-linux-musl, but I get some LD complaints 
> > i.e.
> > 
> > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> > relocation against symbol __fini_array_end
> > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> > relocation against symbol __fini_array_start
> > 
> > Those are some warnings we recently added to LD, perhaps I need to rebuild 
> > the
> > libc.a with PIE as well.  I will try it out, but if anyone has some 
> > suggestions
> > that would be helpful.
> 
> yes, musl does not build libc.a with pic by default,
> either use a gcc configured with --enable-default-pie
> or CC='gcc -fPIC' when building musl.
> 
> after that -static-pie linking should work.
> 
> (maybe musl should have an --enable-static-pie config
> option to make this simpler)

Thank's for confirming.  I tested this out with your tips and it works.

I use musl-cross-make [0] to build musl, all you really need to do is add
'GCC_CONFIG += --enable-default-pie' to your config.mak file.

-Stafford

[0] https://github.com/richfelker/musl-cross-make

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Christophe Lyon]

On Mon, 5 Nov 2018 at 20:46, Richard Henderson  wrote:
>
> On 11/4/18 9:05 AM, Stafford Horne wrote:
> > I have had some inqueries into helping
> > bootstrap some linux nommu machines.
>
> For nommu, we'd need to implement an FDPIC ABI.
>
> Otherwise, code segments cannot be mapped separately
> from data segments.  I believe that the arm (32bit)
> port has recently added support for this, so you may
> be able to find patches from which to crib.
>

The arm patches are not committed yet, they are still under discussion.
I plan to submit v4 soon.

>
> r~

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson]

On 11/4/18 9:05 AM, Stafford Horne wrote:
> I have had some inqueries into helping
> bootstrap some linux nommu machines.

For nommu, we'd need to implement an FDPIC ABI.

Otherwise, code segments cannot be mapped separately
from data segments.  I believe that the arm (32bit)
port has recently added support for this, so you may
be able to find patches from which to crib.


r~

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Rich Felker]

On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_SPEC
> >>> +#define LINK_SPEC "%{h*} \
> >>> +   %{static:-Bstatic}\
> >>> +   %{shared:-shared} \
> >>> +   %{symbolic:-Bsymbolic}\
> >>> +   %{!static:\
> >>> + %{rdynamic:-export-dynamic} \
> >>> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> >>> +
> >>> +#endif /* GCC_OR1K_LINUX_H */
> >>
> >> note that because of the -static-pie mess each
> >> target needs a more complicated LINK_SPEC now.
> > 
> > Hello,
> > 
> > Does something like this look better?
> > 
> > --- a/gcc/config/or1k/linux.h
> > +++ b/gcc/config/or1k/linux.h
> > @@ -37,8 +37,9 @@
> > %{static:-Bstatic}  \
> > %{shared:-shared}   \
> > %{symbolic:-Bsymbolic}  \
> > -   %{!static:  \
> > +   %{!static:%{!static-pie:\
> >   %{rdynamic:-export-dynamic}   \
> > - %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> > + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
> > +   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
> >  
> >  #endif /* GCC_OR1K_LINUX_H */
> 
> looks ok.
> 
> > I have tested this out with or1k-linux-musl, but I get some LD complaints 
> > i.e.
> > 
> > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> > relocation against symbol __fini_array_end
> > .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> > relocation against symbol __fini_array_start
> > 
> > Those are some warnings we recently added to LD, perhaps I need to rebuild 
> > the
> > libc.a with PIE as well.  I will try it out, but if anyone has some 
> > suggestions
> > that would be helpful.
> 
> yes, musl does not build libc.a with pic by default,
> either use a gcc configured with --enable-default-pie
> or CC='gcc -fPIC' when building musl.
> 
> after that -static-pie linking should work.
> 
> (maybe musl should have an --enable-static-pie config
> option to make this simpler)

For practical purposes, if you want to use static pie, you need a
default-pie toolchain. This is because _every_ static lib you might
link needs to be built with -fPIE (or -fPIC), and ensuring that
happens on a package-by-package basis is largely impractical; at least
it's on the same order of magnitude of difficulty as other systems
integration/packaging tasks.

However from the musl side it might make sense to produce a libc_pic.a
as part of the build process. This would make it easy to replace
libc.a with libc_pic.a if desired, and could also be used as the basis
for linking libc.so and to allow production of a stripped-down libc.so
that only includes symbols a fixed set of binaries depend on. We could
discuss something like this on the musl list.

Rich

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Szabolcs Nagy]

On 04/11/18 09:05, Stafford Horne wrote:
> On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
>> On 27/10/18 05:37, Stafford Horne wrote:
...
>>> +#undef LINK_SPEC
>>> +#define LINK_SPEC "%{h*}   \
>>> +   %{static:-Bstatic}  \
>>> +   %{shared:-shared}   \
>>> +   %{symbolic:-Bsymbolic}  \
>>> +   %{!static:  \
>>> + %{rdynamic:-export-dynamic}   \
>>> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
>>> +
>>> +#endif /* GCC_OR1K_LINUX_H */
>>
>> note that because of the -static-pie mess each
>> target needs a more complicated LINK_SPEC now.
> 
> Hello,
> 
> Does something like this look better?
> 
> --- a/gcc/config/or1k/linux.h
> +++ b/gcc/config/or1k/linux.h
> @@ -37,8 +37,9 @@
> %{static:-Bstatic}  \
> %{shared:-shared}   \
> %{symbolic:-Bsymbolic}  \
> -   %{!static:  \
> +   %{!static:%{!static-pie:\
>   %{rdynamic:-export-dynamic}   \
> - %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
> +   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
>  
>  #endif /* GCC_OR1K_LINUX_H */

looks ok.

> I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.
> 
> .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> relocation against symbol __fini_array_end
> .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
> relocation against symbol __fini_array_start
> 
> Those are some warnings we recently added to LD, perhaps I need to rebuild the
> libc.a with PIE as well.  I will try it out, but if anyone has some 
> suggestions
> that would be helpful.

yes, musl does not build libc.a with pic by default,
either use a gcc configured with --enable-default-pie
or CC='gcc -fPIC' when building musl.

after that -static-pie linking should work.

(maybe musl should have an --enable-static-pie config
option to make this simpler)

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> On 27/10/18 05:37, Stafford Horne wrote:
> > +++ b/gcc/config/or1k/linux.h
> > @@ -0,0 +1,44 @@
> > +/* Linux Definitions for OpenRISC.
> > +   Copyright (C) 2018 Free Software Foundation, Inc.
> > +   Contributed by Stafford Horne.
> > +
> > +   This file is part of GCC.
> > +
> > +   GCC is free software; you can redistribute it and/or modify it
> > +   under the terms of the GNU General Public License as published
> > +   by the Free Software Foundation; either version 3, or (at your
> > +   option) any later version.
> > +
> > +   GCC is distributed in the hope that it will be useful, but WITHOUT
> > +   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> > +   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> > +   License for more details.
> > +
> > +   You should have received a copy of the GNU General Public License
> > +   along with GCC; see the file COPYING3.  If not see
> > +   .  */
> > +
> > +#ifndef GCC_OR1K_LINUX_H
> > +#define GCC_OR1K_LINUX_H
> > +
> > +/* elfos.h should have already been included.  Now just override
> > +   any conflicting definitions and add any extras.  */
> > +
> > +#define TARGET_OS_CPP_BUILTINS() \
> > +  GNU_USER_TARGET_OS_CPP_BUILTINS ()
> > +
> > +#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-or1k.so.1"
> > +
> > +#undef MUSL_DYNAMIC_LINKER
> > +#define MUSL_DYNAMIC_LINKER  "/lib/ld-musl-or1k.so.1"
> > +
> > +#undef LINK_SPEC
> > +#define LINK_SPEC "%{h*}   \
> > +   %{static:-Bstatic}  \
> > +   %{shared:-shared}   \
> > +   %{symbolic:-Bsymbolic}  \
> > +   %{!static:  \
> > + %{rdynamic:-export-dynamic}   \
> > + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> > +
> > +#endif /* GCC_OR1K_LINUX_H */
> 
> note that because of the -static-pie mess each
> target needs a more complicated LINK_SPEC now.

Hello,

Does something like this look better?

--- a/gcc/config/or1k/linux.h
+++ b/gcc/config/or1k/linux.h
@@ -37,8 +37,9 @@
%{static:-Bstatic}  \
%{shared:-shared}   \
%{symbolic:-Bsymbolic}  \
-   %{!static:  \
+   %{!static:%{!static-pie:\
  %{rdynamic:-export-dynamic}   \
- %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+ %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
+   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
 
 #endif /* GCC_OR1K_LINUX_H */

I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.

.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
relocation against symbol __fini_array_end
.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic 
relocation against symbol __fini_array_start

Those are some warnings we recently added to LD, perhaps I need to rebuild the
libc.a with PIE as well.  I will try it out, but if anyone has some suggestions
that would be helpful.

> i think there could be a generic LINK_SPEC in
> config/linux.h or config/gnu-user.h that works
> for simple targets (the start file spec is
> already there) so this complex logic is not
> repeated everywhere.
> 
> or even do the -no-dynamic-linker logic in
> LINK_PIE_SPEC in gcc.c for all targets, not
> just linux, so backends don't need to do
> anything to get static-pie to work.

I see, yeah, it seems this could be made generic.  I would defer myself working
on making this generic until after or1k port is in.  Sorry, I dont have much
time to make sure it doesnt break everything/anything.  Also, To tell you the
truth I haven't heard of anyone ever running OpenRISC with pie, it has always
been something on my todo list though.  I have had some inqueries into helping
bootstrap some linux nommu machines.

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Jeff Law]

On 10/30/18 4:35 PM, Stafford Horne wrote:
> On Tue, Oct 30, 2018 at 10:49:53AM -0500, Segher Boessenkool wrote:
>> On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote:
>>> Hello,
>>>
>>> On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote:
 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.
>>>
>>> Just to be clear, when you say 'as-is' did you mean the original v3 patch?  
>>> Or
>>> are you referring to followup patch I posted with the some_offset (from) -
>>> some_offset (to) logic.
>>
>> Either.  Both.  I meant the orig big patch, v3 if that's what it was.
> 
> Alright, thanks, I just didnt want to misunderstand.
Also note that it's my understanding the issues I raised during my
review have been dealt with as have Joseph's.  My inclination would be
to accept the port when Stafford & rth think it's ready.


Jeff

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Tue, Oct 30, 2018 at 03:57:03PM +, Richard Henderson wrote:
> On 10/30/18 12:18 PM, Stafford Horne wrote:
> > OK, I was just being lazy allowing the spill.  Do you think the split/expand
> > would be an RTL using left shift / right shift?  Can you think of something
> > more clever?  Since "real" hardware does not usually support shifts with an
> > immediate we will need 1 instruction to load shift amount. i.e.
> > 
> >   l.ori %0, r0, 24
> >   l.sll %1, %1, %0
> >   l.sra %0, %1, %0
> 
> This clobbers %1.

Right, it was just a rough idea to create another r/r pattern.
 
> So, ouch.  I think we will want to avoid creating this particular pattern in
> the first place unless l.exts exists then.  We would use another pattern like
> 
> (define_insn "*sign_extend_mem"
>   [(set (match_operand:SI 0 "register_operand" "=r")
>   (sign_extend:SI
> (match_operand:HI 1 "memory_operand" "m")))]
>   ""
>   "l.lhs\t%0, %1")
> 
> following the TARGET_SEXT pattern.  In this way combine can use this pattern
> without getting us into trouble with the register allocator later.

OK, thats simple enough then.  I had thought you were asking for creating
another r/r pattern using define_split.  That might be better than requiring a
memory load/store to do sign extension, but I guess we can optimize that later
if needed. (Thats what my original thought was.)

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Tue, Oct 30, 2018 at 10:49:53AM -0500, Segher Boessenkool wrote:
> On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote:
> > Hello,
> > 
> > On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote:
> > > 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.
> > 
> > Just to be clear, when you say 'as-is' did you mean the original v3 patch?  
> > Or
> > are you referring to followup patch I posted with the some_offset (from) -
> > some_offset (to) logic.
> 
> Either.  Both.  I meant the orig big patch, v3 if that's what it was.

Alright, thanks, I just didnt want to misunderstand.

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Segher Boessenkool]

On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote:
> Hello,
> 
> On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote:
> > 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.
> 
> Just to be clear, when you say 'as-is' did you mean the original v3 patch?  Or
> are you referring to followup patch I posted with the some_offset (from) -
> some_offset (to) logic.

Either.  Both.  I meant the orig big patch, v3 if that's what it was.

I am not a global reviewer; this is all just my opinion :-)


Segher

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson]

On 10/30/18 12:18 PM, Stafford Horne wrote:
> OK, I was just being lazy allowing the spill.  Do you think the split/expand
> would be an RTL using left shift / right shift?  Can you think of something
> more clever?  Since "real" hardware does not usually support shifts with an
> immediate we will need 1 instruction to load shift amount. i.e.
> 
>   l.ori %0, r0, 24
>   l.sll %1, %1, %0
>   l.sra %0, %1, %0

This clobbers %1.

So, ouch.  I think we will want to avoid creating this particular pattern in
the first place unless l.exts exists then.  We would use another pattern like

(define_insn "*sign_extend_mem"
  [(set (match_operand:SI 0 "register_operand" "=r")
(sign_extend:SI
  (match_operand:HI 1 "memory_operand" "m")))]
  ""
  "l.lhs\t%0, %1")

following the TARGET_SEXT pattern.  In this way combine can use this pattern
without getting us into trouble with the register allocator later.

> I am submitting patches on my git branch or1k-port-4. Just in case you want to
> track progress.

Will do.


r~

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Segher Boessenkool]

On Tue, Oct 30, 2018 at 08:26:00PM +0900, Stafford Horne wrote:
> On Mon, Oct 29, 2018 at 04:42:43PM +, Richard Henderson wrote:
> > On 10/29/18 4:34 PM, Segher Boessenkool wrote:
> > > Is there some better documentation available?  This is what google found
> > > for me.  I would have like better docs (more compact, etc.)  Links to
> > > such would be great to have in readings.html :-)
> > 
> > https://openrisc.io/architecture
> > 
> > and especially the v1.2 pdf linked from there
> > 
> > https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.2-rev0.pdf
> 
> Thanks,
> 
> I meant to point this out during my previous reply.  Also, I will send a patch
> for adding this to wwwdocs.
> 
>   https://www.gnu.org/software/gcc/readings.html

I figure out how I most likely found the out-of-date page btw: I googled
"openrisc xori" (no quotes).


Segher

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

Hello,

On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote:
> 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.

Just to be clear, when you say 'as-is' did you mean the original v3 patch?  Or
are you referring to followup patch I posted with the some_offset (from) -
some_offset (to) logic.

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Sun, Oct 28, 2018 at 01:56:29AM +, Richard Henderson wrote:
> On 10/27/18 5:37 AM, Stafford Horne wrote:
> > +(define_insn "zero_extendhisi2"
> > +  [(set (match_operand:SI 0 "register_operand""=r,r")
> > +   (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
> > +  ""
> > +  "@
> > +   l.exthz\t%0, %1
> > +   l.lhz\t%0, %1"
> > +  [(set_attr "insn_support" "sext,*")])
> > +
> > +(define_insn "zero_extendqisi2"
> > +  [(set (match_operand:SI 0 "register_operand""=r,r")
> > +   (zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "r,m")))]
> > +  ""
> > +  "@
> > +   l.extbz\t%0, %1
> > +   l.lbz\t%0, %1"
> > +  [(set_attr "insn_support" "sext,*")])
> 
> The !sext r/r case is just l.andi.

OK.

> > +;; Sign extension patterns
> > +
> > +;; We can do memory extensions with a single load
> > +(define_insn "extendhisi2"
> > +  [(set (match_operand:SI 0 "register_operand" "=r,r")
> > +   (sign_extend:SI (match_operand:HI 1 "nonimmediate_operand"  "r,m")))]
> > +  ""
> > +  "@
> > +   l.exths\t%0, %1
> > +   l.lhs\t%0, %1"
> > +  [(set_attr "insn_support" "sext,*")])
> > +
> > +(define_insn "extendqisi2"
> > +  [(set (match_operand:SI 0 "register_operand" "=r,r")
> > +   (sign_extend:SI (match_operand:QI 1 "nonimmediate_operand"  "r,m")))]
> > +  ""
> > +  "@
> > +   l.extbs\t%0, %1
> > +   l.lbs\t%0, %1"
> > +  [(set_attr "insn_support" "sext,*")])
> 
> You don't really want to give the register allocator no choice but to spill to
> memory in the !sext case.  Another r/r case with a splitter that is 
> conditional
> on !sext would work.

OK, I was just being lazy allowing the spill.  Do you think the split/expand
would be an RTL using left shift / right shift?  Can you think of something
more clever?  Since "real" hardware does not usually support shifts with an
immediate we will need 1 instruction to load shift amount. i.e.

  l.ori %0, r0, 24
  l.sll %1, %1, %0
  l.sra %0, %1, %0

If we support shift with immediate it would just be:

  l.slli %1, %1, 24
  l.srai %0, %1, 24

But, I cant think of anything better.

> Otherwise, OK.

Thanks,

I am submitting patches on my git branch or1k-port-4. Just in case you want to
track progress.

 - Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Mon, Oct 29, 2018 at 04:42:43PM +, Richard Henderson wrote:
> On 10/29/18 4:34 PM, Segher Boessenkool wrote:
> > Is there some better documentation available?  This is what google found
> > for me.  I would have like better docs (more compact, etc.)  Links to
> > such would be great to have in readings.html :-)
> 
> https://openrisc.io/architecture
> 
> and especially the v1.2 pdf linked from there
> 
> https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.2-rev0.pdf

Thanks,

I meant to point this out during my previous reply.  Also, I will send a patch
for adding this to wwwdocs.

  https://www.gnu.org/software/gcc/readings.html

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson]

On 10/29/18 4:34 PM, Segher Boessenkool wrote:
> Is there some better documentation available?  This is what google found
> for me.  I would have like better docs (more compact, etc.)  Links to
> such would be great to have in readings.html :-)

https://openrisc.io/architecture

and especially the v1.2 pdf linked from there

https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.2-rev0.pdf


r~

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Segher Boessenkool]

On Mon, Oct 29, 2018 at 10:34:25PM +0900, Stafford Horne wrote:
> On Sun, Oct 28, 2018 at 11:16:13PM +, Richard Henderson wrote:
> > On 10/28/18 2:57 AM, Segher Boessenkool wrote:
> > > Is this correct?  Should this be unsigned (u16 and K)?
> > 
> > No, l.xori is signed.
> 
> Right, sorry, I didn't have enough time to look at this at all this morning.  
> It
> is correct.
> 
> It looks like the documentation for this page [1] is generated from the cgen 
> cpu
> descriptions that were removed from binutils-gdb back in 2014.  Ccing cgen who
> seem to maintain this web page.  How can we go about getting it regenerated?

Is there some better documentation available?  This is what google found
for me.  I would have like better docs (more compact, etc.)  Links to
such would be great to have in readings.html :-)


Segher

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Szabolcs Nagy]

On 27/10/18 05:37, Stafford Horne wrote:
> +++ b/gcc/config/or1k/linux.h
> @@ -0,0 +1,44 @@
> +/* Linux Definitions for OpenRISC.
> +   Copyright (C) 2018 Free Software Foundation, Inc.
> +   Contributed by Stafford Horne.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published
> +   by the Free Software Foundation; either version 3, or (at your
> +   option) any later version.
> +
> +   GCC is distributed in the hope that it will be useful, but WITHOUT
> +   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> +   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> +   License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   .  */
> +
> +#ifndef GCC_OR1K_LINUX_H
> +#define GCC_OR1K_LINUX_H
> +
> +/* elfos.h should have already been included.  Now just override
> +   any conflicting definitions and add any extras.  */
> +
> +#define TARGET_OS_CPP_BUILTINS() \
> +  GNU_USER_TARGET_OS_CPP_BUILTINS ()
> +
> +#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-or1k.so.1"
> +
> +#undef MUSL_DYNAMIC_LINKER
> +#define MUSL_DYNAMIC_LINKER  "/lib/ld-musl-or1k.so.1"
> +
> +#undef LINK_SPEC
> +#define LINK_SPEC "%{h*} \
> +   %{static:-Bstatic}\
> +   %{shared:-shared} \
> +   %{symbolic:-Bsymbolic}\
> +   %{!static:\
> + %{rdynamic:-export-dynamic} \
> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
> +
> +#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each
target needs a more complicated LINK_SPEC now.

i think there could be a generic LINK_SPEC in
config/linux.h or config/gnu-user.h that works
for simple targets (the start file spec is
already there) so this complex logic is not
repeated everywhere.

or even do the -no-dynamic-linker logic in
LINK_PIE_SPEC in gcc.c for all targets, not
just linux, so backends don't need to do
anything to get static-pie to work.

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

On Sun, Oct 28, 2018 at 11:16:13PM +, Richard Henderson wrote:
> On 10/28/18 2:57 AM, Segher Boessenkool wrote:
> >> +(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)?
> 
> No, l.xori is signed.

Right, sorry, I didn't have enough time to look at this at all this morning.  It
is correct.

It looks like the documentation for this page [1] is generated from the cgen cpu
descriptions that were removed from binutils-gdb back in 2014.  Ccing cgen who
seem to maintain this web page.  How can we go about getting it regenerated?

cpu/or1korbis.cpu

(alu-insn-uimm and)
(alu-insn-uimm or)
(alu-insn-simm xor)

(define-pmacro (alu-carry-insn-simm mnemonic)
  (begin
(dni (.sym l- mnemonic "i")
 (.str "l." mnemonic "i reg/reg/simm16")
 ((MACH ORBIS-MACHS))
 (.str "l." mnemonic "i $rD,$rA,$simm16")
 (+ (.sym OPC_ (.upcase mnemonic) "I") rD rA simm16)

[1] https://sourceware.org/cgen/gen-doc/openrisc-insn.html#insns

-Stafford

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Segher Boessenkool]

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

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson]

On 10/28/18 2:57 AM, Segher Boessenkool wrote:
>> +(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)?

No, l.xori is signed.


r~

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

Hi Segher,

Thank you for the review and thank you for all the help up until now.

On Sat, Oct 27, 2018 at 09:57:30PM -0500, Segher Boessenkool wrote:
> 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.

OK, I will fix.

> > +  /* Number of bytes saved on the stack for outgoing/sub-fucntion args.  */
> 
> Typo ("function").

OK.

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

OK.

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

OK.

> > +/* 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?


/* Helper function for use with INITIAL_ELIMINATION_OFFSET.  */

static HOST_WIDE_INT
or1k_stack_pointer_offset (int from)
{
   HOST_WIDE_INT offset;

  /* Set OFFSET to the offset from the stack pointer.  */
  switch (from)
{
/* Incoming args are all the way up at the previous frame.  */
case HARD_FRAME_POINTER_REGNUM:
case ARG_POINTER_REGNUM:
  offset = cfun->machine->total_size;
  break;

/* Local args grow downward from the saved registers.  */
case FRAME_POINTER_REGNUM:
  offset = cfun->machine->args_size + cfun->machine->local_vars_size;
  break;

default:
  gcc_unreachable ();
}

  return offset;
}

/* Helper for defining INITIAL_ELIMINATION_OFFSET.
   We allow the following eliminiations:
 FP -> HARD_FP or SP
 AP -> HARD_FP or SP

   HARD_FP and AP are actually the same.  */

HOST_WIDE_INT
or1k_initial_elimination_offset (int from, int to)
{
  return or1k_stack_pointer_offset (from) - or1k_stack_pointer_offset (to);
}


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

Sure, I will remove all ATTRIBUTE_UNUSED instances.

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

OK.

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

OK. I found a few ore too, thanks.

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

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

OK.

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

Ok.

> > +#define TARGET_RETURN_IN_MEMORYor1k_return_in_memory
> 
> > +#defineTARGET_PASS_BY_REFERENCE or1k_pass_by_reference
> 
> These two have a tab instead of a space (as the rest do).

OK, also some TARGET_* are aligned and some not.  Will fix.

> > +#define WCHAR_TYPE_SIZE32
> 
> And this.

OK.

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

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Segher Boessenkool]

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 PmodeSImode
> +#define FUNCTION_MODESImode

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"
> +  [(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

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson]

On 10/27/18 5:37 AM, Stafford Horne wrote:
> +(define_insn "zero_extendhisi2"
> +  [(set (match_operand:SI 0 "register_operand""=r,r")
> + (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
> +  ""
> +  "@
> +   l.exthz\t%0, %1
> +   l.lhz\t%0, %1"
> +  [(set_attr "insn_support" "sext,*")])
> +
> +(define_insn "zero_extendqisi2"
> +  [(set (match_operand:SI 0 "register_operand""=r,r")
> + (zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "r,m")))]
> +  ""
> +  "@
> +   l.extbz\t%0, %1
> +   l.lbz\t%0, %1"
> +  [(set_attr "insn_support" "sext,*")])

The !sext r/r case is just l.andi.


> +;; Sign extension patterns
> +
> +;; We can do memory extensions with a single load
> +(define_insn "extendhisi2"
> +  [(set (match_operand:SI 0 "register_operand" "=r,r")
> + (sign_extend:SI (match_operand:HI 1 "nonimmediate_operand"  "r,m")))]
> +  ""
> +  "@
> +   l.exths\t%0, %1
> +   l.lhs\t%0, %1"
> +  [(set_attr "insn_support" "sext,*")])
> +
> +(define_insn "extendqisi2"
> +  [(set (match_operand:SI 0 "register_operand" "=r,r")
> + (sign_extend:SI (match_operand:QI 1 "nonimmediate_operand"  "r,m")))]
> +  ""
> +  "@
> +   l.extbs\t%0, %1
> +   l.lbs\t%0, %1"
> +  [(set_attr "insn_support" "sext,*")])

You don't really want to give the register allocator no choice but to spill to
memory in the !sext case.  Another r/r case with a splitter that is conditional
on !sext would work.

Otherwise, OK.


r~

[PATCH v3 3/3] or1k: gcc: initial support for openrisc

[Stafford Horne]

-mm-dd  Stafford Horne  
Richard Henderson  
Joel Sherrill  

gcc/ChangeLog:

* common/config/or1k/or1k-common.c: New file.
* config/or1k/*: New.
* config.gcc (or1k*-*-*): New.
* configure.ac (or1k*-*-*): New test for openrisc tls.
* configure: Regenerated.
* doc/install.texi: Document OpenRISC triplets.
* doc/invoke.texi: Document OpenRISC arguments.
* doc/md.texi: Document OpenRISC.
---
 gcc/common/config/or1k/or1k-common.c |   41 +
 gcc/config.gcc   |   45 +
 gcc/config/or1k/constraints.md   |   55 +
 gcc/config/or1k/elf.h|   42 +
 gcc/config/or1k/elf.opt  |   33 +
 gcc/config/or1k/linux.h  |   44 +
 gcc/config/or1k/or1k-protos.h|   38 +
 gcc/config/or1k/or1k.c   | 2186 ++
 gcc/config/or1k/or1k.h   |  392 +
 gcc/config/or1k/or1k.md  |  907 +++
 gcc/config/or1k/or1k.opt |   67 +
 gcc/config/or1k/predicates.md|   84 +
 gcc/config/or1k/rtems.h  |   30 +
 gcc/config/or1k/t-or1k   |   22 +
 gcc/config/or1k/t-rtems  |3 +
 gcc/configure|   12 +
 gcc/configure.ac |   12 +
 gcc/doc/install.texi |   19 +
 gcc/doc/invoke.texi  |   68 +
 gcc/doc/md.texi  |   25 +
 20 files changed, 4125 insertions(+)
 create mode 100644 gcc/common/config/or1k/or1k-common.c
 create mode 100644 gcc/config/or1k/constraints.md
 create mode 100644 gcc/config/or1k/elf.h
 create mode 100644 gcc/config/or1k/elf.opt
 create mode 100644 gcc/config/or1k/linux.h
 create mode 100644 gcc/config/or1k/or1k-protos.h
 create mode 100644 gcc/config/or1k/or1k.c
 create mode 100644 gcc/config/or1k/or1k.h
 create mode 100644 gcc/config/or1k/or1k.md
 create mode 100644 gcc/config/or1k/or1k.opt
 create mode 100644 gcc/config/or1k/predicates.md
 create mode 100644 gcc/config/or1k/rtems.h
 create mode 100644 gcc/config/or1k/t-or1k
 create mode 100644 gcc/config/or1k/t-rtems

diff --git a/gcc/common/config/or1k/or1k-common.c 
b/gcc/common/config/or1k/or1k-common.c
new file mode 100644
index 000..044e843fd19
--- /dev/null
+++ b/gcc/common/config/or1k/or1k-common.c
@@ -0,0 +1,41 @@
+/* Common hooks for OpenRISC
+   Copyright (C) 2018 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "diagnostic-core.h"
+#include "tm.h"
+#include "common/common-target.h"
+#include "common/common-target-def.h"
+#include "opts.h"
+#include "flags.h"
+
+/* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */
+static const struct default_options or1k_option_optimization_table[] =
+  {
+/* Enable section anchors by default at -O1 or higher.  */
+{ OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
+{ OPT_LEVELS_NONE, 0, NULL, 0 }
+  };
+
+#undef TARGET_OPTION_OPTIMIZATION_TABLE
+#define TARGET_OPTION_OPTIMIZATION_TABLE or1k_option_optimization_table
+
+struct gcc_targetm_common targetm_common = TARGETM_COMMON_INITIALIZER;
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 71f62a2aba2..0dc2ac4b879 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -468,6 +468,9 @@ nios2-*-*)
 nvptx-*-*)
cpu_type=nvptx
;;
+or1k*-*-*)
+   cpu_type=or1k
+   ;;
 powerpc*-*-*spe*)
cpu_type=powerpcspe
extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h 
spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
@@ -2464,6 +2467,48 @@ nvptx-*)
tm_file="${tm_file} nvptx/offload.h"
fi
;;
+or1k*-*-*)
+   tm_file="elfos.h ${tm_file}"
+   tmake_file="${tmake_file} or1k/t-or1k"
+   # Force .init_array support.  The configure script cannot always
+   # automatically detect that GAS supports it, yet we require it.
+   gcc_cv_initfini_array=yes
+
+   # Handle --with-multilib-list=...
+   or1k_multilibs="${with_multilib_list}"
+   if test "$or1k_multilibs" = "default"; then
+   or1k_multilibs="mcmov,msoft-mul,msoft-div"
+   fi
+   or1k_multilibs=`echo $or1k_multilibs | sed -e 's/,/ /g'`
+   for or1k_multilib in ${or1k_multilibs}; do
+   case