> 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
On 08/12/15 17:55, David Miller wrote:
From: Sebastian Huber
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 a
From: Sebastian Huber
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.
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.hu..
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 ma
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
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.
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
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
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
On 09/29/2015 08:00 AM, Richard Biener wrote:
On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law 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 themse
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 (I
On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law 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 mak
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
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 "mainten
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 dow
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,
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 wrote:
+#define TARGET_LRA_P hook_bool_void_true
Are we at the point there this should be the default, and old
ports shou
From: Oleg Endo
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
On Sep 27, 2015, at 6:29 PM, Jeff Law 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
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 wrote:
> >>> +#define TARGET_LRA_P hook_bool_void_true
> >>
> >> Are we at the point there this should
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 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 n
On Wed, 9 Sep 2015, Mike Stump wrote:
> On Sep 8, 2015, at 9:41 PM, David Miller 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
From: Eric Botcazou
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.
> > 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
From: Eric Botcazou
Date: Sat, 12 Sep 2015 16:04:09 +0200
> You need to update https://gcc.gnu.org/backends.html
Done.
From: David Miller
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 re
From: Richard Henderson
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
>
On 09/12/2015 10:44 PM, David Miller wrote:
> From: Eric Botcazou
> 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.
>
> N
From: Eric Botcazou
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 th
> 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
On 09/11/2015 12:43 PM, David Miller wrote:
> From: David Miller
> 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
From: David Miller
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?
On Sep 8, 2015, at 9:41 PM, David Miller 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.
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
35 matches
Mail list logo
