[PATCH] Convert SPARC to LRA

[PATCH] Convert SPARC to LRA

[David Miller]

The following patch converts the sparc backend over to LRA.

The three major obstacles to overcome were:

1) The funky "U" constraint.  It was a register constraint, but
   did not evaluate to a register class, and was used to help
   handling unaligned integer register pairs.

   It turns out to be unnecessary, since GENERAL_REGS plus
   HARD_REGNO_MODE_OK() do the job just fine now.

2) Sparc generates unreasonable amounts of subregging because
   it did not define PROMOTE_MODE().  All of the subreg LRA
   problems I was running into went away once I simply added
   the define.

3) The sethi/or patterns accepting direct symbol references and
   similar should not be available when flag_pic.

The testsuite runs really well, there are no regressions and in
fact the LRA conversion fixes some failures.

I'm therefore reasonably confident in these changes, but I will
not apply them just yet to give the other sparc maintainers some
time to review and give feedback.

2015-09-08  David S. Miller  <davem@davemloft.net>

	* config/sparc/constraints.md: Make "U" constraint a real register
	constraint.
	* config/sparc/sparc.c (TARGET_LRA_P): Define.
	(D_MODES, DF_MODES): Add missing cast.
	(TF_MODES, TF_MODES_NO_S): Include T_MODE.
	(OF_MODES, OF_MODES_NO_S): Include O_MODE.
	(sparc_register_move_cost): Decrease Niagara/UltrsSPARC memory
	cost to 8.
	* config/sparc/sparc.h (PROMOTE_MODE): Define.
	* config/sparc/sparc.md (*movsi_lo_sum, *movsi_high): Do not
	provide these insn when flag_pic.

diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index e12efa1..7a18879 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -44,6 +44,8 @@
 (define_register_constraint "h" "(TARGET_V9 && TARGET_V8PLUS ? I64_REGS : NO_REGS)"
  "64-bit global or out register in V8+ mode")
 
+(define_register_constraint "U" "(TARGET_ARCH32 ? GENERAL_REGS : NO_REGS)")
+
 ;; Floating-point constant constraints
 
 (define_constraint "G"
@@ -135,51 +137,6 @@
       (match_code "mem")
       (match_test "memory_ok_for_ldd (op)")))
 
-;; This awkward register constraint is necessary because it is not
-;; possible to express the "must be even numbered register" condition
-;; using register classes.  The problem is that membership in a
-;; register class requires that all registers of a multi-regno
-;; register be included in the set.  It is add_to_hard_reg_set
-;; and in_hard_reg_set_p which populate and test regsets with these
-;; semantics.
-;;
-;; So this means that we would have to put both the even and odd
-;; register into the register class, which would not restrict things
-;; at all.
-;;
-;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a
-;; full solution either.  In fact, even though IRA uses the macro
-;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from
-;; use in certain modes, it still can allocate an odd hard register
-;; for DImode values.  This is due to how IRA populates the table
-;; ira_useful_class_mode_regs[][].  It suffers from the same problem
-;; as using a register class to describe this restriction.  Namely, it
-;; sets both the odd and even part of an even register pair in the
-;; regset.  Therefore IRA can and will allocate odd registers for
-;; DImode values on 32-bit.
-;;
-;; There are legitimate cases where DImode values can end up in odd
-;; hard registers, the most notable example is argument passing.
-;;
-;; What saves us is reload and the DImode splitters.  Both are
-;; necessary.  The odd register splitters cannot match if, for
-;; example, we have a non-offsetable MEM.  Reload will notice this
-;; case and reload the address into a single hard register.
-;;
-;; The real downfall of this awkward register constraint is that it does
-;; not evaluate to a true register class like a bonafide use of
-;; define_register_constraint would.  This currently means that we cannot
-;; use LRA on Sparc, since the constraint processing of LRA really depends
-;; upon whether an extra constraint is for registers or not.  It uses
-;; reg_class_for_constraint, and checks it against NO_REGS.
-(define_constraint "U"
- "Pseudo-register or hard even-numbered integer register"
- (and (match_test "TARGET_ARCH32")
-      (match_code "reg")
-      (ior (match_test "REGNO (op) < FIRST_PSEUDO_REGISTER")
-	   (not (match_test "reload_in_progress && reg_renumber [REGNO (op)] < 0")))
-      (match_test "register_ok_for_ldd (op)")))
-
 ;; Equivalent to 'T' but available in 64-bit mode
 (define_memory_constraint "W"
  "Memory reference for 'e' constraint floating-point register"
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index ed8a166..b41800c 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -808,6 +808,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_CAN_ELIMINATE
 #define TARGET_CAN_ELIMINATE sparc_can_eliminate
 
+#undef TARGET_LRA_P
+#define TARGET_LRA_P hook_bool_void_true
+
 #undef  TARGET_PREFERRED_RELOAD_CLASS
 #define TARGET_PREFERRED_RELOAD_CLASS sparc_preferred_reload_class
 
@@ -4691,7 +4694,7 @@ enum sparc_mode_class {
   ((1 << (int) H_MODE) | (1 << (int) S_MODE) | (1 << (int) SF_MODE))
 
 /* Modes for double-word and smaller quantities.  */
-#define D_MODES (S_MODES | (1 << (int) D_MODE) | (1 << DF_MODE))
+#define D_MODES (S_MODES | (1 << (int) D_MODE) | (1 << (int) DF_MODE))
 
 /* Modes for quad-word and smaller quantities.  */
 #define T_MODES (D_MODES | (1 << (int) T_MODE) | (1 << (int) TF_MODE))
@@ -4703,22 +4706,24 @@ enum sparc_mode_class {
 #define SF_MODES ((1 << (int) S_MODE) | (1 << (int) SF_MODE))
 
 /* Modes for double-float and smaller quantities.  */
-#define DF_MODES (SF_MODES | (1 << (int) D_MODE) | (1 << DF_MODE))
+#define DF_MODES (SF_MODES | (1 << (int) D_MODE) | (1 << (int) DF_MODE))
 
 /* Modes for quad-float and smaller quantities.  */
-#define TF_MODES (DF_MODES | (1 << (int) TF_MODE))
+#define TF_MODES (DF_MODES | (1 << (int) T_MODE) | (1 << (int) TF_MODE))
 
 /* Modes for quad-float pairs and smaller quantities.  */
-#define OF_MODES (TF_MODES | (1 << (int) OF_MODE))
+#define OF_MODES (TF_MODES | (1 << (int) O_MODE) | (1 << (int) OF_MODE))
 
 /* Modes for double-float only quantities.  */
 #define DF_MODES_NO_S ((1 << (int) D_MODE) | (1 << (int) DF_MODE))
 
 /* Modes for quad-float and double-float only quantities.  */
-#define TF_MODES_NO_S (DF_MODES_NO_S | (1 << (int) TF_MODE))
+#define TF_MODES_NO_S \
+  (DF_MODES_NO_S | (1 << (int) T_MODE) | (1 << (int) TF_MODE))
 
 /* Modes for quad-float pairs and double-float only quantities.  */
-#define OF_MODES_NO_S (TF_MODES_NO_S | (1 << (int) OF_MODE))
+#define OF_MODES_NO_S \
+  (TF_MODES_NO_S | (1 << (int) O_MODE) | (1 << (int) OF_MODE))
 
 /* Modes for condition codes.  */
 #define CC_MODES (1 << (int) CC_MODE)
@@ -11188,7 +11193,7 @@ sparc_register_move_cost (machine_mode mode ATTRIBUTE_UNUSED,
 	  || sparc_cpu == PROCESSOR_NIAGARA2
 	  || sparc_cpu == PROCESSOR_NIAGARA3
 	  || sparc_cpu == PROCESSOR_NIAGARA4)
-	return 12;
+	return 8;
 
       return 6;
     }
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index 2cbe0d9..8343671 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -452,6 +452,17 @@ extern enum cmodel sparc_cmodel;
 \f
 /* target machine storage layout */
 
+/* Define this macro if it is advisable to hold scalars in registers
+   in a wider mode than that declared by the program.  In such cases,
+   the value is constrained to be within the bounds of the declared
+   type, but kept valid in the wider mode.  The signedness of the
+   extension may differ from that of the type.  */
+
+#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE)	\
+  if (GET_MODE_CLASS (MODE) == MODE_INT		\
+      && GET_MODE_SIZE (MODE) < (TARGET_ARCH64 ? 8 : 4)) \
+    (MODE) = TARGET_ARCH64 ? DImode : SImode;
+
 /* Define this if most significant bit is lowest numbered
    in instructions that operate on numbered bit-fields.  */
 #define BITS_BIG_ENDIAN 1
diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index 5b9f051..f514d9f 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -1467,13 +1467,13 @@
   [(set (match_operand:SI 0 "register_operand" "=r")
 	(lo_sum:SI (match_operand:SI 1 "register_operand" "r")
                    (match_operand:SI 2 "immediate_operand" "in")))]
-  ""
+  "! flag_pic"
   "or\t%1, %%lo(%a2), %0")
 
 (define_insn "*movsi_high"
   [(set (match_operand:SI 0 "register_operand" "=r")
 	(high:SI (match_operand:SI 1 "immediate_operand" "in")))]
-  ""
+  "! flag_pic"
   "sethi\t%%hi(%a1), %0")
 
 ;; The next two patterns must wrap the SYMBOL_REF in an UNSPEC

Re: [PATCH] Convert SPARC to LRA

[Mike Stump]

On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> wrote:
> +#define TARGET_LRA_P hook_bool_void_true

Are we at the point there this should be the default, and old ports should just define to false, if they really need to?  I’m using nothing but LRA as well.

Re: [PATCH] Convert SPARC to LRA

[Hans-Peter Nilsson]

On Wed, 9 Sep 2015, Mike Stump wrote:

> On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> wrote:
> > +#define TARGET_LRA_P hook_bool_void_true
>
> Are we at the point there this should be the default, and old
> ports should just define to false, if they really need to?

I think no.  For one, we don't have proper target documentation
updates for LRA.  What does it need?  What is outdated?

Also, give ample time for gcc releases of odd ports with LRA to
get into the public and cover most of the inevitable remaining
bugs.  Not even sh has moved over due to remaining issues.  Let
the reports come in - and be fixed.  Let's revisit in a year or
two.

brgds, H-P

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote:
> On Wed, 9 Sep 2015, Mike Stump wrote:
>
>> On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> wrote:
>>> +#define TARGET_LRA_P hook_bool_void_true
>>
>> Are we at the point there this should be the default, and old
>> ports should just define to false, if they really need to?
>
> I think no.  For one, we don't have proper target documentation
> updates for LRA.  What does it need?  What is outdated?
>
> Also, give ample time for gcc releases of odd ports with LRA to
> get into the public and cover most of the inevitable remaining
> bugs.  Not even sh has moved over due to remaining issues.  Let
> the reports come in - and be fixed.  Let's revisit in a year or
> two.
I don't think we're there yet either -- many ports still require some 
guidance from Vlad to get working with LRA.

It *may* be time to decree that any new ports must use the LRA path 
rather than reload.  I'm still on the fence with that.

jeff

Re: [PATCH] Convert SPARC to LRA

[Oleg Endo]

On Sun, 2015-09-27 at 19:29 -0600, Jeff Law wrote:
> On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote:
> > On Wed, 9 Sep 2015, Mike Stump wrote:
> >
> >> On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> wrote:
> >>> +#define TARGET_LRA_P hook_bool_void_true
> >>
> >> Are we at the point there this should be the default, and old
> >> ports should just define to false, if they really need to?
> >
> > I think no.  For one, we don't have proper target documentation
> > updates for LRA.  What does it need?  What is outdated?
> >
> > Also, give ample time for gcc releases of odd ports with LRA to
> > get into the public and cover most of the inevitable remaining
> > bugs.  Not even sh has moved over due to remaining issues.  Let
> > the reports come in - and be fixed.  Let's revisit in a year or
> > two.
> I don't think we're there yet either -- many ports still require some 
> guidance from Vlad to get working with LRA.
> 
> It *may* be time to decree that any new ports must use the LRA path 
> rather than reload.  I'm still on the fence with that.

LRA on SH seems to work without GCC test suite failures.  However, I'd
expect that there still hidden bugs not covered by the test suite.  SH's
R0 spill failures are greatly reduced with LRA, although some hacks had
to be added to the SH backend to make it work at all.  Despite that, we
see quite some significant code size increases compared to reload.  If
the difference wasn't that big, we'd probably turn LRA on by default for
SH in GCC 6...

Cheers,
Oleg

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Oleg Endo <oleg.endo@t-online.de>
Date: Mon, 28 Sep 2015 21:26:14 +0900

> LRA on SH seems to work without GCC test suite failures.  However, I'd
> expect that there still hidden bugs not covered by the test suite.  SH's
> R0 spill failures are greatly reduced with LRA, although some hacks had
> to be added to the SH backend to make it work at all.  Despite that, we
> see quite some significant code size increases compared to reload.  If
> the difference wasn't that big, we'd probably turn LRA on by default for
> SH in GCC 6...

One weakness I noticed while working on the sparc conversion is that
the bootstrap of the compiler tests reload/LRA better than the
testsuite does.

Which is unfortunate, because bootstrap failures are significantly harder
to analyze and debug than individual testsuite cases.

Re: [PATCH] Convert SPARC to LRA

[Mike Stump]

On Sep 27, 2015, at 6:29 PM, Jeff Law <law@redhat.com> wrote:
> I don't think we're there yet either -- many ports still require some guidance from Vlad to get working with LRA.
> 
> It *may* be time to decree that any new ports must use the LRA path rather than reload.  I'm still on the fence with that.

So, I think it makes sense to change the default for LRA to on now.  Port maintainers for which this isn’t the right choice (sh, cause code size regressions), can then default it to off in the port.  We can then use the #define LRA in the port as an indicator that things are not fine on that port and ideally LRA should be enhanced to make the port work better.  When no port has a #define left, we can then safely rm -rf all the non-LRA code.

Re: [PATCH] Convert SPARC to LRA

[Vladimir Makarov]

On 09/27/2015 09:29 PM, Jeff Law wrote:
> On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote:
>> On Wed, 9 Sep 2015, Mike Stump wrote:
>>
>>> On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> wrote:
>>>> +#define TARGET_LRA_P hook_bool_void_true
>>>
>>> Are we at the point there this should be the default, and old
>>> ports should just define to false, if they really need to?
>>
>> I think no.  For one, we don't have proper target documentation
>> updates for LRA.  What does it need?  What is outdated?
>>
>> Also, give ample time for gcc releases of odd ports with LRA to
>> get into the public and cover most of the inevitable remaining
>> bugs.  Not even sh has moved over due to remaining issues.  Let
>> the reports come in - and be fixed.  Let's revisit in a year or
>> two.
> I don't think we're there yet either -- many ports still require some 
> guidance from Vlad to get working with LRA.
>
There are more ports using reload than LRA now.  Even some major ports 
(e.g. ppc64) did not switch to LRA.

I usually say target maintainers, that if they don't switch LRA they 
probably will have problems with maintenance and development in a long 
perspective.  New things are easier to implement in LRA.  Intel 
developers recognized this long ago and implemented some new 
optimizations in RA (the last biggest one was pic hard register reuse).  
According to them, it would be much harder to implement this in reload.

On the other hand a lot of work was done in reload during long years to 
accommodate some unique target requirements as SH.  A lot of efforts is 
needed to implement this in LRA to achieve the same performance as reload.

> It *may* be time to decree that any new ports must use the LRA path 
> rather than reload.  I'm still on the fence with that.

That is probably a good policy I see now.  Porting LRA might be not an 
easy task as a lot of target hooks (and even insn definitions, e.g. 
hints *?!) were written taking reload algorithms into account. LRA uses 
different ones and many hook implementations are misleading.  Many 
target ports are just in a maintenance mode and simply there are no 
resources to do LRA port for this targets.  So I believe reload will 
stay for a long time.

Re: [PATCH] Convert SPARC to LRA

[Segher Boessenkool]

On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote:
> There are more ports using reload than LRA now.  Even some major ports 
> (e.g. ppc64) did not switch to LRA.

There still are some failures in the testsuite (ICEs even) so we're
not there yet.

> I usually say target maintainers, that if they don't switch LRA they 
> probably will have problems with maintenance and development in a long 
> perspective.  New things are easier to implement in LRA.

It is also true that new *ports* are easier to do with LRA than with
reload :-)

> >It *may* be time to decree that any new ports must use the LRA path 
> >rather than reload.  I'm still on the fence with that.
> 
> That is probably a good policy I see now.  Porting LRA might be not an 
> easy task as a lot of target hooks (and even insn definitions, e.g. 
> hints *?!) were written taking reload algorithms into account. LRA uses 
> different ones and many hook implementations are misleading.  Many 
> target ports are just in a maintenance mode and simply there are no 
> resources to do LRA port for this targets.  So I believe reload will 
> stay for a long time.

We can at least change the default to LRA, so new ports get it unless
they like to hurt themselves.

I don't think it makes sense to keep reload around *just* for the ports
that are in "maintenance mode": by the time we are down to *just* those
ports, it makes more sense to relabel them as "unmaintained".


Segher

Re: [PATCH] Convert SPARC to LRA

[Oleg Endo]

On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:

> We can at least change the default to LRA, so new ports get it unless
> they like to hurt themselves.
> 
> I don't think it makes sense to keep reload around *just* for the ports
> that are in "maintenance mode": by the time we are down to *just* those
> ports, it makes more sense to relabel them as "unmaintained".

Just for my understanding ... what's the definition of "maintenance
mode" or "unmaintained"?

Cheers,
Oleg

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/29/2015 07:19 AM, Oleg Endo wrote:
> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
>
>> We can at least change the default to LRA, so new ports get it unless
>> they like to hurt themselves.
>>
>> I don't think it makes sense to keep reload around *just* for the ports
>> that are in "maintenance mode": by the time we are down to *just* those
>> ports, it makes more sense to relabel them as "unmaintained".
>
> Just for my understanding ... what's the definition of "maintenance
> mode" or "unmaintained"?
I'm not sure there's any formal definition.

If the port isn't getting tested, bugs aren't getting fixed, fails to 
build, etc then it's probably a good bet you could put it into the 
unmaintained bucket.

If the port does get occasional fixes (primarily driven by BZs), but not 
getting updated on a regular basis (such as conversion to LRA, 
conversion to RTL prologue/epilogue, etc), may be only getting 
occasional testing, etc.  Then it's probably fair to call it in 
maintenance mode.  A great example IMHO would be the m68k.

I would say we probably have many ports in maintenance mode right now. 
Not sure if any are in the unmaintained mode with perhaps the exception 
of interix.

jeff

Re: [PATCH] Convert SPARC to LRA

[Richard Biener]

On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law <law@redhat.com> wrote:
> On 09/29/2015 07:19 AM, Oleg Endo wrote:
>>
>> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
>>
>>> We can at least change the default to LRA, so new ports get it unless
>>> they like to hurt themselves.
>>>
>>> I don't think it makes sense to keep reload around *just* for the ports
>>> that are in "maintenance mode": by the time we are down to *just* those
>>> ports, it makes more sense to relabel them as "unmaintained".
>>
>>
>> Just for my understanding ... what's the definition of "maintenance
>> mode" or "unmaintained"?
>
> I'm not sure there's any formal definition.
>
> If the port isn't getting tested, bugs aren't getting fixed, fails to build,
> etc then it's probably a good bet you could put it into the unmaintained
> bucket.
>
> If the port does get occasional fixes (primarily driven by BZs), but not
> getting updated on a regular basis (such as conversion to LRA, conversion to
> RTL prologue/epilogue, etc), may be only getting occasional testing, etc.
> Then it's probably fair to call it in maintenance mode.  A great example
> IMHO would be the m68k.

Another criteria would be available hardware for which both the PA and
alpha ports
are a good example.  When you can't buy new hardware then targets that
could formerly host GCC quickly rot to the state where only cross-compilation
is viable (and having "old" GCC is good enough).

> I would say we probably have many ports in maintenance mode right now. Not
> sure if any are in the unmaintained mode with perhaps the exception of
> interix.

I'd say that all ports not in maintainance mode should be at least secondary
archs as we can expect maintainers to be around to keep it at the quality
level we expect for secondary targets.  Now I'd like to do the opposite
conclusion and declare all non-primary/secondary targets as in
maintainance mode ... ;)
We have 49 targets (counting directories) and 7 of them compose the list of
primary and secondary triplets.

Richard.

> jeff

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/29/2015 08:00 AM, Richard Biener wrote:
> On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law <law@redhat.com> wrote:
>> On 09/29/2015 07:19 AM, Oleg Endo wrote:
>>>
>>> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
>>>
>>>> We can at least change the default to LRA, so new ports get it
>>>> unless they like to hurt themselves.
>>>>
>>>> I don't think it makes sense to keep reload around *just* for
>>>> the ports that are in "maintenance mode": by the time we are
>>>> down to *just* those ports, it makes more sense to relabel them
>>>> as "unmaintained".
>>>
>>>
>>> Just for my understanding ... what's the definition of
>>> "maintenance mode" or "unmaintained"?
>>
>> I'm not sure there's any formal definition.
>>
>> If the port isn't getting tested, bugs aren't getting fixed, fails
>> to build, etc then it's probably a good bet you could put it into
>> the unmaintained bucket.
>>
>> If the port does get occasional fixes (primarily driven by BZs),
>> but not getting updated on a regular basis (such as conversion to
>> LRA, conversion to RTL prologue/epilogue, etc), may be only getting
>> occasional testing, etc. Then it's probably fair to call it in
>> maintenance mode.  A great example IMHO would be the m68k.
>
> Another criteria would be available hardware for which both the PA
> and alpha ports are a good example.  When you can't buy new hardware
> then targets that could formerly host GCC quickly rot to the state
> where only cross-compilation is viable (and having "old" GCC is good
> enough).
Very true. Actually the PA is the best example there.  Alpha I believe 
has a functional-enough QEMU port to do real work and m68k has Aranym 
which I've used to bootstrap m68k within the last 18 months.  Hell, I 
think Aranym actually ran faster than the last shipping real hardware!

> I'd say that all ports not in maintainance mode should be at least
> secondary archs as we can expect maintainers to be around to keep it
> at the quality level we expect for secondary targets.  Now I'd like
> to do the opposite conclusion and declare all non-primary/secondary
> targets as in maintainance mode ... ;) We have 49 targets (counting
> directories) and 7 of them compose the list of primary and secondary
> triplets.
I could live with that.

jeff

Re: [PATCH] Convert SPARC to LRA

[Sebastian Huber]

On 30/09/15 04:07, Jeff Law wrote:
>>> If the port does get occasional fixes (primarily driven by BZs),
>>> but not getting updated on a regular basis (such as conversion to
>>> LRA, conversion to RTL prologue/epilogue, etc), may be only getting
>>> occasional testing, etc. Then it's probably fair to call it in
>>> maintenance mode.  A great example IMHO would be the m68k.
>>
>> Another criteria would be available hardware for which both the PA
>> and alpha ports are a good example.  When you can't buy new hardware
>> then targets that could formerly host GCC quickly rot to the state
>> where only cross-compilation is viable (and having "old" GCC is good
>> enough).
> Very true. Actually the PA is the best example there.  Alpha I believe 
> has a functional-enough QEMU port to do real work and m68k has Aranym 
> which I've used to bootstrap m68k within the last 18 months.  Hell, I 
> think Aranym actually ran faster than the last shipping real hardware! 

You can still buy m68k based chips (e.g. Freescale ColdFire) for 
embedded systems.

http://www.freescale.com/products/more-processors/32-bit-mcu-and-mcp/coldfire-plus-coldfire-mcus-mpus:PC68KCF

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/28/2015 02:28 PM, Segher Boessenkool wrote:
> On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote:
>> There are more ports using reload than LRA now.  Even some major ports
>> (e.g. ppc64) did not switch to LRA.
>
> There still are some failures in the testsuite (ICEs even) so we're
> not there yet.
>
>> I usually say target maintainers, that if they don't switch LRA they
>> probably will have problems with maintenance and development in a long
>> perspective.  New things are easier to implement in LRA.
>
> It is also true that new *ports* are easier to do with LRA than with
> reload :-)
Right.  And if we set the expectation that a new port must use LRA, then 
I think we're fine.

>
> We can at least change the default to LRA, so new ports get it unless
> they like to hurt themselves.
>
> I don't think it makes sense to keep reload around *just* for the ports
> that are in "maintenance mode": by the time we are down to *just* those
> ports, it makes more sense to relabel them as "unmaintained".
FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it 
fell over pretty early.  Essentially LRA doesn't seem to be cc0-aware in 
split_reg as ultimately inserted something between a cc0-setter and 
cc0-user.  Oops.


jeff

Re: [PATCH] Convert SPARC to LRA

[Vladimir Makarov]

On 09/29/2015 09:43 AM, Jeff Law wrote:
> FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it 
> fell over pretty early.  Essentially LRA doesn't seem to be cc0-aware 
> in split_reg as ultimately inserted something between a cc0-setter and 
> cc0-user.  Oops.
>
Yes, that is true.  When I started to work on LRA, I decided to ignore 
cc0 first.  But since then, no progress was made on this front.

I guess the support of cc0 can be implemented for reasonable amount of 
time.  It is just a priority issue.  I still have a lot PRs for the 
targets already using LRA.

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/29/2015 09:04 PM, Vladimir Makarov wrote:
> On 09/29/2015 09:43 AM, Jeff Law wrote:
>> FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it
>> fell over pretty early.  Essentially LRA doesn't seem to be cc0-aware
>> in split_reg as ultimately inserted something between a cc0-setter and
>> cc0-user.  Oops.
>>
> Yes, that is true.  When I started to work on LRA, I decided to ignore
> cc0 first.  But since then, no progress was made on this front.
No worries.


>
> I guess the support of cc0 can be implemented for reasonable amount of
> time.  It is just a priority issue.  I still have a lot PRs for the
> targets already using LRA.
I wouldn't suggest making cc0 support a significant priority.   I'd be 
more likely to push for deprecating cc0 targets first.

jeff

Re: [PATCH] Convert SPARC to LRA

[Segher Boessenkool]

On Wed, Sep 30, 2015 at 09:15:17AM -0600, Jeff Law wrote:
> >I guess the support of cc0 can be implemented for reasonable amount of
> >time.  It is just a priority issue.  I still have a lot PRs for the
> >targets already using LRA.
> I wouldn't suggest making cc0 support a significant priority.   I'd be 
> more likely to push for deprecating cc0 targets first.

It looks like most cc0 targets would be pretty easy to convert, if anyone
can do testing anyway ;-)


Segher

Re: [PATCH] Convert SPARC to LRA

[Jeff Law]

On 09/30/2015 10:15 AM, Segher Boessenkool wrote:
> On Wed, Sep 30, 2015 at 09:15:17AM -0600, Jeff Law wrote:
>>> I guess the support of cc0 can be implemented for reasonable amount of
>>> time.  It is just a priority issue.  I still have a lot PRs for the
>>> targets already using LRA.
>> I wouldn't suggest making cc0 support a significant priority.   I'd be
>> more likely to push for deprecating cc0 targets first.
>
> It looks like most cc0 targets would be pretty easy to convert, if anyone
> can do testing anyway ;-)
v850, h8300 and m68k are all testable.  The first two via traditional 
simulators, the latter via aranym.  I just haven't seen the benefit for 
converting them outweighing the time, so I haven't tried.

If you wanted to take a stab (and I'm sure the v850 would be easiest), 
I'll sign up for the regression testing & debugging.


Jeff

Re: [PATCH] Convert SPARC to LRA

[Peter Bergner]

On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
> On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote:
> > There are more ports using reload than LRA now.  Even some major ports 
> > (e.g. ppc64) did not switch to LRA.
> 
> There still are some failures in the testsuite (ICEs even) so we're
> not there yet.

I've started to looking through the failures with a target of getting POWER
converted to LRA before the switch to stage3.  From a quick scan, I see what
looks like two different ICEs on multiple tests and one wrong code gen issue.

The first ICE seems to be due to a conversion to long double and LRA ends
up going into a infinite loop spilling things until it hits a threshold and
quits with an ICE.  I haven't spent enough time to determine whether this
is a LRA or port issue yet though.  The simplest test case I have at the
moment is:

bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ cat bug2.i
void
foo (long double *ldb1, double *db1)
{
  *ldb1 = *db1;
}
bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ /home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/ -S -O1 -mvsx -S bug2.i
bug2.i: In function ‘foo’:
bug2.i:5:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

 }
 ^
0x10962903 lra_constraints(bool)
	/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/lra-constraints.c:4351
0x10942af7 lra(_IO_FILE*)
	/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/lra.c:2298
0x108c0ac7 do_reload
	/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/ira.c:5391
0x108c1183 execute
	/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/ira.c:5562


After IRA, things are pretty simple, with just the following one insn which needs
a reload/spill, since we don't have memory to memory ops on POWER:

(insn 7 4 10 2 (parallel [
            (set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
                (float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8 A64])))
            (use (const_double:DF 0.0 [0x0.0p+0]))
        ]) bug2.i:4 445 {*extenddftf2_internal}
     (expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
        (expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
            (nil))))

In LRA, comes along and gives us the following which looks good:

(insn 7 4 11 2 (parallel [
            (set (reg:TF 159)
                (float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8 A64])))
            (use (const_double:DF 0.0 [0x0.0p+0]))
        ]) bug2.i:4 445 {*extenddftf2_internal}
     (expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
        (expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
            (nil))))

(insn 11 7 10 2 (set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
        (reg:TF 159)) bug2.i:4 435 {*movtf_64bit_dm}
     (nil))

but for some reason, it thinks reg 159 needs reloading and gives us:

(insn 7 4 12 2 (parallel [
            (set (reg:TF 159)
                (float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8 A64])))
            (use (const_double:DF 0.0 [0x0.0p+0]))
        ]) bug2.i:4 445 {*extenddftf2_internal}
     (expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
        (expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
            (nil))))

(insn 12 7 11 2 (set (reg:TF 160 [159])
        (reg:TF 159)) bug2.i:4 435 {*movtf_64bit_dm}
     (nil))

(insn 11 12 10 2 (set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
        (reg:TF 160 [159])) bug2.i:4 435 {*movtf_64bit_dm}
     (nil))

and we end up doing it again and again and...until we hit the reload threshold
and ICE.  That's as far as I've gotten at this point.  Comments welcome since
I've had to put this on the shelf at the moment while working on next year's
work schedule for our team.

I haven't had a chance to look into the other ICE or wrong code gen issue yet,
but will eventually will get to those.

Peter

Re: [PATCH] Convert SPARC to LRA

[Peter Bergner]

On Tue, 2015-09-29 at 09:27 -0500, Peter Bergner wrote:
> The first ICE seems to be due to a conversion to long double and LRA ends
> up going into a infinite loop spilling things until it hits a threshold and
> quits with an ICE.  I haven't spent enough time to determine whether this
> is a LRA or port issue yet though.  The simplest test case I have at the
> moment is:
> 
> bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ cat bug2.i
> void
> foo (long double *ldb1, double *db1)
> {
>   *ldb1 = *db1;
> }
> bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ /home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/ -S -O1 -mvsx -S bug2.i
> bug2.i: In function ‘foo’:
> bug2.i:5:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

So working with Segher and Mike offline, this ends up being a problem
with rs6000.md's *extenddftf2_internal pattern using the constraint
"ws" in alternative 2.  TFmode variables are not allowed in Altivec
registers, so this pattern should be using the "d" constraint instead.
I'm testing a patch.

Peter

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 08 Sep 2015 21:41:15 -0700 (PDT)

> I'm therefore reasonably confident in these changes, but I will
> not apply them just yet to give the other sparc maintainers some
> time to review and give feedback.

Richard, Eric, any objections?

Re: [PATCH] Convert SPARC to LRA

[Richard Henderson]

On 09/11/2015 12:43 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 08 Sep 2015 21:41:15 -0700 (PDT)
> 
>> I'm therefore reasonably confident in these changes, but I will
>> not apply them just yet to give the other sparc maintainers some
>> time to review and give feedback.
> 
> Richard, Eric, any objections?
> 

Nope.


r~

Re: [PATCH] Convert SPARC to LRA

[Eric Botcazou]

> Richard, Eric, any objections?

Do we really need to promote to 64-bit if TARGET_ARCH64?  Most 32-bit 
instructions are still available.  Otherwise this looks good to me.

You need to update https://gcc.gnu.org/backends.html

-- 
Eric Botcazou

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Sat, 12 Sep 2015 16:04:09 +0200

>> Richard, Eric, any objections?
> 
> Do we really need to promote to 64-bit if TARGET_ARCH64?  Most 32-bit 
> instructions are still available.  Otherwise this looks good to me.

No, we don't, we can just promote to 32-bit.  I'll make that adjustment
and update the backends page as well.

Thanks.

Re: [PATCH] Convert SPARC to LRA

[Richard Henderson]

On 09/12/2015 10:44 PM, David Miller wrote:
> From: Eric Botcazou <ebotcazou@adacore.com>
> Date: Sat, 12 Sep 2015 16:04:09 +0200
> 
>>> Richard, Eric, any objections?
>>
>> Do we really need to promote to 64-bit if TARGET_ARCH64?  Most 32-bit 
>> instructions are still available.  Otherwise this looks good to me.
> 
> No, we don't, we can just promote to 32-bit.  I'll make that adjustment
> and update the backends page as well.

There's a possibility of benefit though -- br and movr only work with DImode.
You may want to examine the generated code to decide one way or another.

It's possible that the extra comparison instructions don't really matter
compared with the larger spill slot, but you never know...


r~

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Richard Henderson <rth@redhat.com>
Date: Mon, 14 Sep 2015 10:20:00 -0700

> There's a possibility of benefit though -- br and movr only work with DImode.
> You may want to examine the generated code to decide one way or another.
> 
> It's possible that the extra comparison instructions don't really matter
> compared with the larger spill slot, but you never know...

And another issue is that I get expr.c:expand_expr_real_1() assertion
failures when I try to use SImode for 64-bit, specifically the one in
this code sequence:

          /* Get the signedness to be used for this variable.  Ensure we get
             the same mode we got when the variable was declared.  */
          if (code != SSA_NAME)
            pmode = promote_decl_mode (exp, &unsignedp);
          else if ((g = SSA_NAME_DEF_STMT (ssa_name))
                   && gimple_code (g) == GIMPLE_CALL
                   && !gimple_call_internal_p (g))
            pmode = promote_function_mode (type, mode, &unsignedp,
                                           gimple_call_fntype (g),
                                           2);
          else
            pmode = promote_ssa_mode (ssa_name, &unsignedp);
          gcc_assert (GET_MODE (decl_rtl) == pmode);

There are some other issues I'm having troubles resolving for 64-bit
native bootstraps as well, and I am probably going to revert the LRA
sparc changes unless I can resolve them by the end of today.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Mon, 14 Sep 2015 11:30:29 -0700 (PDT)

> There are some other issues I'm having troubles resolving for 64-bit
> native bootstraps as well, and I am probably going to revert the LRA
> sparc changes unless I can resolve them by the end of today.

So I was actually able to resolve these problems, and committed the
following patch.

The big take-aways are:

1) Since we can only access SFmode/SImode/etc. in FP_REGS but not
   necessarily in EXTRA_FP_REGS, we have to tell LRA that secondary
   memory is needed when moving such a mode between those two classes.

2) HARD_REGNO_CALLER_SAVE_MODE's default should really be reconsidered.
   If the caller has an explicit mode in mind we should just use it
   instead just going to choose_hard_reg_mode().  That causes stupid
   things like using a DFmode register to spill an SFmode value and
   all the subregging that results from that.

3) It's amazing how much we get away with in RELOAD, particular wrt.
   to addressing.  Here all of the "(set x (HIGH (SYMBOLIC...)))"
   were always available even when flag_pic and this was never
   noticed before.

====================
[PATCH] Fix LRA regressions on 64-bit SPARC.

gcc/
	* config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
	Declare.
	* config/sparc/sparc.c (sparc_secondary_memory_needed): New
	function.
	* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
	(HARD_REGNO_CALLER_SAVE_MODE): Define.
	* config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
	(setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
	(embmedany_losum, embmedany_brsum, embmedany_textuhi)
	(embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
	provide when flag_pic.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227847 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog                   | 14 ++++++++++++++
 gcc/config/sparc/sparc-protos.h |  2 ++
 gcc/config/sparc/sparc.c        | 20 ++++++++++++++++++++
 gcc/config/sparc/sparc.h        | 14 +++++++++-----
 gcc/config/sparc/sparc.md       | 32 ++++++++++++++++----------------
 5 files changed, 61 insertions(+), 21 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 76566ca..42faf2e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17 @@
+2015-09-17  David S. Miller  <davem@davemloft.net>
+
+	* config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
+	Declare.
+	* config/sparc/sparc.c (sparc_secondary_memory_needed): New
+	function.
+	* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
+	(HARD_REGNO_CALLER_SAVE_MODE): Define.
+	* config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
+	(setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
+	(embmedany_losum, embmedany_brsum, embmedany_textuhi)
+	(embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
+	provide when flag_pic.
+
 2015-09-17  Kaz Kojima  <kkojima@gcc.gnu.org>
 
 	* config/sh/sh.c (label_ref_list_d_pool): Adjust to
diff --git a/gcc/config/sparc/sparc-protos.h b/gcc/config/sparc/sparc-protos.h
index 1431437..18192fd 100644
--- a/gcc/config/sparc/sparc-protos.h
+++ b/gcc/config/sparc/sparc-protos.h
@@ -62,6 +62,8 @@ extern bool constant_address_p (rtx);
 extern bool legitimate_pic_operand_p (rtx);
 extern rtx sparc_legitimize_reload_address (rtx, machine_mode, int, int,
 					    int, int *win);
+extern bool sparc_secondary_memory_needed (enum reg_class, enum reg_class,
+					   machine_mode);
 extern void load_got_register (void);
 extern void sparc_emit_call_insn (rtx, rtx);
 extern void sparc_defer_case_vector (rtx, rtx, int);
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index b41800c..f4ad68d 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -12283,6 +12283,26 @@ sparc_expand_vector_init (rtx target, rtx vals)
   emit_move_insn (target, mem);
 }
 
+bool sparc_secondary_memory_needed (enum reg_class class1, enum reg_class class2,
+				    machine_mode mode)
+{
+  if (FP_REG_CLASS_P (class1) != FP_REG_CLASS_P (class2))
+    {
+      if (! TARGET_VIS3
+	  || GET_MODE_SIZE (mode) > 8
+	  || GET_MODE_SIZE (mode) < 4)
+	return true;
+      return false;
+    }
+
+  if (GET_MODE_SIZE (mode) == 4
+      && ((class1 == FP_REGS && class2 == EXTRA_FP_REGS)
+	  || (class1 == EXTRA_FP_REGS && class2 == FP_REGS)))
+    return true;
+
+  return false;
+}
+
 /* Implement TARGET_SECONDARY_RELOAD.  */
 
 static reg_class_t
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index 8343671..1f26232 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -747,6 +747,12 @@ extern int sparc_mode_class[];
    register window instruction in the prologue.  */
 #define HARD_REGNO_RENAME_OK(FROM, TO) ((FROM) != 1)
 
+/* Select a register mode required for caller save of hard regno REGNO.  */
+#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
+    (((MODE) == VOIDmode) ? \
+     choose_hard_reg_mode ((REGNO), (NREGS), false) : \
+     (MODE))
+
 #define MODES_TIEABLE_P(MODE1, MODE2) sparc_modes_tieable_p (MODE1, MODE2)
 
 /* Specify the registers used for certain standard purposes.
@@ -1044,12 +1050,10 @@ extern char leaf_reg_remap[];
   (SPARC_SETHI_P ((unsigned HOST_WIDE_INT) (X) & GET_MODE_MASK (SImode)))
 
 /* On SPARC when not VIS3 it is not possible to directly move data
-   between GENERAL_REGS and FP_REGS.  */
+   between GENERAL_REGS and FP_REGS.  We also cannot move 4-byte values
+   between FP_REGS and EXTRA_FP_REGS.  */
 #define SECONDARY_MEMORY_NEEDED(CLASS1, CLASS2, MODE) \
-  ((FP_REG_CLASS_P (CLASS1) != FP_REG_CLASS_P (CLASS2)) \
-   && (! TARGET_VIS3 \
-       || GET_MODE_SIZE (MODE) > 8 \
-       || GET_MODE_SIZE (MODE) < 4))
+  sparc_secondary_memory_needed (CLASS1, CLASS2, MODE)
 
 /* Get_secondary_mem widens its argument to BITS_PER_WORD which loses on v9
    because the movsi and movsf patterns don't handle r/f moves.
diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index f514d9f..e6a1831 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -1745,105 +1745,105 @@
 (define_insn "*sethi_di_medlow"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (match_operand:DI 1 "symbolic_operand" "")))]
-  "TARGET_CM_MEDLOW && check_pic (1)"
+  "TARGET_CM_MEDLOW && !flag_pic"
   "sethi\t%%hi(%a1), %0")
 
 (define_insn "*losum_di_medlow"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (match_operand:DI 2 "symbolic_operand" "")))]
-  "TARGET_CM_MEDLOW"
+  "TARGET_CM_MEDLOW && !flag_pic"
   "or\t%1, %%lo(%a2), %0")
 
 (define_insn "seth44"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "symbolic_operand" "")] UNSPEC_SETH44)))]
-  "TARGET_CM_MEDMID"
+  "TARGET_CM_MEDMID && !flag_pic"
   "sethi\t%%h44(%a1), %0")
 
 (define_insn "setm44"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (unspec:DI [(match_operand:DI 2 "symbolic_operand" "")] UNSPEC_SETM44)))]
-  "TARGET_CM_MEDMID"
+  "TARGET_CM_MEDMID && !flag_pic"
   "or\t%1, %%m44(%a2), %0")
 
 (define_insn "setl44"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (match_operand:DI 2 "symbolic_operand" "")))]
-  "TARGET_CM_MEDMID"
+  "TARGET_CM_MEDMID && !flag_pic"
   "or\t%1, %%l44(%a2), %0")
 
 (define_insn "sethh"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "symbolic_operand" "")] UNSPEC_SETHH)))]
-  "TARGET_CM_MEDANY"
+  "TARGET_CM_MEDANY && !flag_pic"
   "sethi\t%%hh(%a1), %0")
 
 (define_insn "setlm"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "symbolic_operand" "")] UNSPEC_SETLM)))]
-  "TARGET_CM_MEDANY"
+  "TARGET_CM_MEDANY && !flag_pic"
   "sethi\t%%lm(%a1), %0")
 
 (define_insn "sethm"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (unspec:DI [(match_operand:DI 2 "symbolic_operand" "")] UNSPEC_EMB_SETHM)))]
-  "TARGET_CM_MEDANY"
+  "TARGET_CM_MEDANY && !flag_pic"
   "or\t%1, %%hm(%a2), %0")
 
 (define_insn "setlo"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (match_operand:DI 2 "symbolic_operand" "")))]
-  "TARGET_CM_MEDANY"
+  "TARGET_CM_MEDANY && !flag_pic"
   "or\t%1, %%lo(%a2), %0")
 
 (define_insn "embmedany_sethi"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "data_segment_operand" "")] UNSPEC_EMB_HISUM)))]
-  "TARGET_CM_EMBMEDANY && check_pic (1)"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "sethi\t%%hi(%a1), %0")
 
 (define_insn "embmedany_losum"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (match_operand:DI 2 "data_segment_operand" "")))]
-  "TARGET_CM_EMBMEDANY"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "add\t%1, %%lo(%a2), %0")
 
 (define_insn "embmedany_brsum"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (unspec:DI [(match_operand:DI 1 "register_operand" "r")] UNSPEC_EMB_HISUM))]
-  "TARGET_CM_EMBMEDANY"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "add\t%1, %_, %0")
 
 (define_insn "embmedany_textuhi"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "text_segment_operand" "")] UNSPEC_EMB_TEXTUHI)))]
-  "TARGET_CM_EMBMEDANY && check_pic (1)"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "sethi\t%%uhi(%a1), %0")
 
 (define_insn "embmedany_texthi"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (high:DI (unspec:DI [(match_operand:DI 1 "text_segment_operand" "")] UNSPEC_EMB_TEXTHI)))]
-  "TARGET_CM_EMBMEDANY && check_pic (1)"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "sethi\t%%hi(%a1), %0")
 
 (define_insn "embmedany_textulo"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (unspec:DI [(match_operand:DI 2 "text_segment_operand" "")] UNSPEC_EMB_TEXTULO)))]
-  "TARGET_CM_EMBMEDANY"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "or\t%1, %%ulo(%a2), %0")
 
 (define_insn "embmedany_textlo"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (lo_sum:DI (match_operand:DI 1 "register_operand" "r")
                    (match_operand:DI 2 "text_segment_operand" "")))]
-  "TARGET_CM_EMBMEDANY"
+  "TARGET_CM_EMBMEDANY && !flag_pic"
   "or\t%1, %%lo(%a2), %0")
 
 ;; Now some patterns to help reload out a bit.
-- 
2.1.2.532.g19b5d50

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Sat, 12 Sep 2015 16:04:09 +0200

> You need to update https://gcc.gnu.org/backends.html

Done.

Re: [PATCH] Convert SPARC to LRA

[Eric Botcazou]

> > You need to update https://gcc.gnu.org/backends.html
> 
> Done.

Nice work!  Did you keep the 64-bit promotion in PROMOTE_MODE or...?

-- 
Eric Botcazou

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Thu, 17 Sep 2015 23:13:21 +0200

> Did you keep the 64-bit promotion in PROMOTE_MODE or...?

Yes I had to, the compiler aborts() if I make it use SImode on 64-bit.

I'll take a closer look soon.

Re: [PATCH] Convert SPARC to LRA

[Sebastian Huber]

Hello David,

since the LRA patch is still reverted on the trunk, I guess the switch 
to LRA will not happen in GCC 6?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Sebastian Huber <sebastian.huber@embedded-brains.de>
Date: Tue, 8 Dec 2015 11:17:53 +0100

> since the LRA patch is still reverted on the trunk, I guess the
> switch to LRA will not happen in GCC 6?

Indeed, it is unlikely I will have time to work on this for at
least a month.

Re: [PATCH] Convert SPARC to LRA

[Sebastian Huber]

On 08/12/15 17:55, David Miller wrote:
> From: Sebastian Huber <sebastian.huber@embedded-brains.de>
> Date: Tue, 8 Dec 2015 11:17:53 +0100
>
>> since the LRA patch is still reverted on the trunk, I guess the
>> switch to LRA will not happen in GCC 6?
> Indeed, it is unlikely I will have time to work on this for at
> least a month.

Are there any plans to switch the SPARC GCC to LRA for GCC 7 or later?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] Convert SPARC to LRA

[Eric Botcazou]

> Are there any plans to switch the SPARC GCC to LRA for GCC 7 or later?

There are plans to switch SPARC to LRA at some point, but no ETA.

-- 
Eric Botcazou