* sparc build broken...
@ 2012-05-31 21:16 David Miller
2012-05-31 21:42 ` Steven Bosscher
0 siblings, 1 reply; 13+ messages in thread
From: David Miller @ 2012-05-31 21:16 UTC (permalink / raw)
To: steven; +Cc: gcc-patches
Removing output.h from reload1.c broke the sparc build because
sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
reload1.c) references current_function_is_leaf.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 21:16 sparc build broken David Miller
@ 2012-05-31 21:42 ` Steven Bosscher
2012-05-31 22:05 ` David Miller
2012-06-01 16:02 ` Rainer Orth
0 siblings, 2 replies; 13+ messages in thread
From: Steven Bosscher @ 2012-05-31 21:42 UTC (permalink / raw)
To: David Miller; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On Thu, May 31, 2012 at 11:15 PM, David Miller <davem@davemloft.net> wrote:
>
> Removing output.h from reload1.c broke the sparc build because
> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
> reload1.c) references current_function_is_leaf.
I was afraid of some fall-out. This is why target macros must die...
Could you please give the attached patch a try?
Sorry for the inconvenience!
Ciao!
Steven
[-- Attachment #2: fix_sparc_output_h.diff --]
[-- Type: application/octet-stream, Size: 2434 bytes --]
* config/sparc/sparc.h (INITIAL_ELIMINATION_OFFSET): Split out
to new function sparc_initial_elimination_offset.
* config/sparc/sparc.c (sparc_initial_elimination_offset): New function.
* config/sparc/sparc-protos.h (sparc_initial_elimination_offset):
Prototype it.
Index: config/sparc/sparc.h
===================================================================
--- config/sparc/sparc.h (revision 188082)
+++ config/sparc/sparc.h (working copy)
@@ -1105,14 +1105,11 @@ extern char leaf_reg_remap[];
{ FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} }
#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
- do { \
- if ((TO) == STACK_POINTER_REGNUM) \
- (OFFSET) = sparc_compute_frame_size (get_frame_size (), \
- current_function_is_leaf); \
- else \
- (OFFSET) = 0; \
- (OFFSET) += SPARC_STACK_BIAS; \
- } while (0)
+ do \
+ { \
+ (OFFSET) = sparc_initial_elimination_offset ((FROM), (TO)); \
+ } \
+ while (0)
/* Keep the stack pointer constant throughout the function.
This is both an optimization and a necessity: longjmp
Index: config/sparc/sparc.c
===================================================================
--- config/sparc/sparc.c (revision 188082)
+++ config/sparc/sparc.c (working copy)
@@ -4551,6 +4551,23 @@ sparc_compute_frame_size (HOST_WIDE_INT size, int
return frame_size;
}
+/* Implements the macro INITIAL_ELIMINATION_OFFSET, return the OFFSET. */
+
+int
+sparc_initial_elimination_offset (int from, int to)
+{
+ int offset;
+
+ if (to == STACK_POINTER_REGNUM)
+ offset = sparc_compute_frame_size (get_frame_size (),
+ current_function_is_leaf);
+ else
+ offset = 0;
+
+ offset += SPARC_STACK_BIAS;
+ return offset;
+}
+
/* Output any necessary .register pseudo-ops. */
void
Index: config/sparc/sparc-protos.h
===================================================================
--- config/sparc/sparc-protos.h (revision 188082)
+++ config/sparc/sparc-protos.h (working copy)
@@ -37,6 +37,7 @@ extern enum direction function_arg_padding (enum m
extern void order_regs_for_local_alloc (void);
extern HOST_WIDE_INT sparc_compute_frame_size (HOST_WIDE_INT, int);
+extern int sparc_initial_elimination_offset (int, int);
extern void sparc_expand_prologue (void);
extern void sparc_flat_expand_prologue (void);
extern void sparc_expand_epilogue (bool);
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 21:42 ` Steven Bosscher
@ 2012-05-31 22:05 ` David Miller
2012-05-31 23:00 ` Steven Bosscher
2012-05-31 23:13 ` Eric Botcazou
2012-06-01 16:02 ` Rainer Orth
1 sibling, 2 replies; 13+ messages in thread
From: David Miller @ 2012-05-31 22:05 UTC (permalink / raw)
To: stevenb.gcc; +Cc: gcc-patches
From: Steven Bosscher <stevenb.gcc@gmail.com>
Date: Thu, 31 May 2012 23:42:26 +0200
> Could you please give the attached patch a try?
> Sorry for the inconvenience!
I'm sure it works, but function calls are quite expensive on
sparc.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 22:05 ` David Miller
@ 2012-05-31 23:00 ` Steven Bosscher
2012-05-31 23:03 ` David Miller
2012-05-31 23:13 ` Eric Botcazou
1 sibling, 1 reply; 13+ messages in thread
From: Steven Bosscher @ 2012-05-31 23:00 UTC (permalink / raw)
To: David Miller; +Cc: gcc-patches
On Fri, Jun 1, 2012 at 12:05 AM, David Miller <davem@davemloft.net> wrote:
> From: Steven Bosscher <stevenb.gcc@gmail.com>
> Date: Thu, 31 May 2012 23:42:26 +0200
>
>> Could you please give the attached patch a try?
>> Sorry for the inconvenience!
>
> I'm sure it works, but function calls are quite expensive on
> sparc.
There are four eliminable registers on sparc, and for one of them
there already is a function call. On the whole of GCC, will the few
extra function calls be a problem?
FWIW:
targets that have INITIAL_ELIMINATION_OFFSET as a function (i.e. macro
that just calls a function): alpha, arm,avr, bfin, c6x, cr16, cris,
epiphany, fr30, frv, h8300, ix86, ia64, iq2000, lm32, m32c, m68k,
mcore, mep, microblaze, mips, mmix, mn10300, moxie, pa, pdp11,
picochip, rl78, rs6000, rx, s390, score, sh, spu, stormy16, tilegx,
tilepro,
targets that have it as an elaborate macro: m32r, sparc, v850, xtensa,
So SPARC is in the overwhelming minority :-) I'm sure that in the long
list of targets that have INITIAL_ELIMINATION_OFFSET as a call there
are other targets where a call is relatively expensive.
Besides, at least as far as I understand, it's sort-of a "design goal"
for gcc to move from target macros to target hooks. So you're going to
have to deal with some more calls anyway.
The alternative is to put back output.h in a file that really doesn't
need it, other than for some target macros. That seems rather fragile
to me, target hooks/functions are more robust.
Ciao!
Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 23:00 ` Steven Bosscher
@ 2012-05-31 23:03 ` David Miller
0 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2012-05-31 23:03 UTC (permalink / raw)
To: stevenb.gcc; +Cc: gcc-patches
From: Steven Bosscher <stevenb.gcc@gmail.com>
Date: Fri, 1 Jun 2012 01:00:37 +0200
> Besides, at least as far as I understand, it's sort-of a "design goal"
> for gcc to move from target macros to target hooks. So you're going to
> have to deal with some more calls anyway.
I understand, I'm just disappointed :-)
I'll test your fix for real after I finish the work I was trying to
finish when I hit the build regression you introduced.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 22:05 ` David Miller
2012-05-31 23:00 ` Steven Bosscher
@ 2012-05-31 23:13 ` Eric Botcazou
1 sibling, 0 replies; 13+ messages in thread
From: Eric Botcazou @ 2012-05-31 23:13 UTC (permalink / raw)
To: David Miller; +Cc: gcc-patches, stevenb.gcc
> I'm sure it works, but function calls are quite expensive on sparc.
I thought the whole business of the register windows was aimed at making them
quite cheap. :-) This one isn't performance critical anyway, so the fix is
fine I think (without the terminal 's' in "Implements" though).
--
Eric Botcazou
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-05-31 21:42 ` Steven Bosscher
2012-05-31 22:05 ` David Miller
@ 2012-06-01 16:02 ` Rainer Orth
2012-06-01 17:51 ` David Miller
1 sibling, 1 reply; 13+ messages in thread
From: Rainer Orth @ 2012-06-01 16:02 UTC (permalink / raw)
To: Steven Bosscher; +Cc: David Miller, gcc-patches
Steven Bosscher <stevenb.gcc@gmail.com> writes:
> On Thu, May 31, 2012 at 11:15 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Removing output.h from reload1.c broke the sparc build because
>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>> reload1.c) references current_function_is_leaf.
>
> I was afraid of some fall-out. This is why target macros must die...
>
> Could you please give the attached patch a try?
It currently fails like this:
/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:4557:1: error: unused parameter 'from' [-Werror=unused-parameter]
sparc_initial_elimination_offset (int from, int to)
^
I've just restarted the build with from marked unused.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-06-01 16:02 ` Rainer Orth
@ 2012-06-01 17:51 ` David Miller
2012-06-02 21:52 ` David Miller
0 siblings, 1 reply; 13+ messages in thread
From: David Miller @ 2012-06-01 17:51 UTC (permalink / raw)
To: ro; +Cc: stevenb.gcc, gcc-patches
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Fri, 01 Jun 2012 18:01:45 +0200
> Steven Bosscher <stevenb.gcc@gmail.com> writes:
>
>> On Thu, May 31, 2012 at 11:15 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> Removing output.h from reload1.c broke the sparc build because
>>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>>> reload1.c) references current_function_is_leaf.
>>
>> I was afraid of some fall-out. This is why target macros must die...
>>
>> Could you please give the attached patch a try?
>
> It currently fails like this:
>
> /vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:4557:1: error: unused parameter 'from' [-Werror=unused-parameter]
> sparc_initial_elimination_offset (int from, int to)
> ^
>
> I've just restarted the build with from marked unused.
I hit the same problem, but solved it by removing the
'from' parameter entirely.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sparc build broken...
2012-06-01 17:51 ` David Miller
@ 2012-06-02 21:52 ` David Miller
0 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2012-06-02 21:52 UTC (permalink / raw)
To: ro; +Cc: stevenb.gcc, gcc-patches
From: David Miller <davem@davemloft.net>
Date: Fri, 01 Jun 2012 13:50:48 -0400 (EDT)
> I hit the same problem, but solved it by removing the
> 'from' parameter entirely.
To move things forward I committed the following:
--------------------
Restore Sparc build.
gcc/
* config/sparc/sparc.h (INITIAL_ELIMINATION_OFFSET): Split out to
new function sparc_initial_elimination_offset.
* config/sparc/sparc.c (sparc_initial_elimination_offset): New
function.
* config/sparc/sparc-protos.h (sparc_initial_elimination_offset):
Prototype it.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@188142 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 9 +++++++++
gcc/config/sparc/sparc-protos.h | 1 +
gcc/config/sparc/sparc.c | 17 +++++++++++++++++
gcc/config/sparc/sparc.h | 15 ++++++---------
4 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5a43bb7..2eb5720 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2012-06-02 Steven Bosscher <steven@gcc.gnu.org>
+
+ * config/sparc/sparc.h (INITIAL_ELIMINATION_OFFSET): Split out to
+ new function sparc_initial_elimination_offset.
+ * config/sparc/sparc.c (sparc_initial_elimination_offset): New
+ function.
+ * config/sparc/sparc-protos.h (sparc_initial_elimination_offset):
+ Prototype it.
+
2012-06-2 Kenneth Zadeck <zadeck@naturalbridge.com>
* expmed.c (expand_mult, choose_multiplier): Change "2 *
diff --git a/gcc/config/sparc/sparc-protos.h b/gcc/config/sparc/sparc-protos.h
index 52acc09..b03f5cc 100644
--- a/gcc/config/sparc/sparc-protos.h
+++ b/gcc/config/sparc/sparc-protos.h
@@ -37,6 +37,7 @@ extern enum direction function_arg_padding (enum machine_mode, const_tree);
extern void order_regs_for_local_alloc (void);
extern HOST_WIDE_INT sparc_compute_frame_size (HOST_WIDE_INT, int);
+extern int sparc_initial_elimination_offset (int);
extern void sparc_expand_prologue (void);
extern void sparc_flat_expand_prologue (void);
extern void sparc_expand_epilogue (bool);
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 54fce8f..7b1899d 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -4551,6 +4551,23 @@ sparc_compute_frame_size (HOST_WIDE_INT size, int leaf_function)
return frame_size;
}
+/* Implement the macro INITIAL_ELIMINATION_OFFSET, return the OFFSET. */
+
+int
+sparc_initial_elimination_offset (int to)
+{
+ int offset;
+
+ if (to == STACK_POINTER_REGNUM)
+ offset = sparc_compute_frame_size (get_frame_size (),
+ current_function_is_leaf);
+ else
+ offset = 0;
+
+ offset += SPARC_STACK_BIAS;
+ return offset;
+}
+
/* Output any necessary .register pseudo-ops. */
void
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index a2bf09f..234edcf 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -1104,15 +1104,12 @@ extern char leaf_reg_remap[];
{{ FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
{ FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} }
-#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
- do { \
- if ((TO) == STACK_POINTER_REGNUM) \
- (OFFSET) = sparc_compute_frame_size (get_frame_size (), \
- current_function_is_leaf); \
- else \
- (OFFSET) = 0; \
- (OFFSET) += SPARC_STACK_BIAS; \
- } while (0)
+#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
+ do \
+ { \
+ (OFFSET) = sparc_initial_elimination_offset ((TO)); \
+ } \
+ while (0)
/* Keep the stack pointer constant throughout the function.
This is both an optimization and a necessity: longjmp
--
1.7.10
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SPARC build broken
2019-12-05 14:33 ` Jakub Jelinek
@ 2019-12-05 14:40 ` David Edelsohn
0 siblings, 0 replies; 13+ messages in thread
From: David Edelsohn @ 2019-12-05 14:40 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Joseph Myers, GCC Patches, David Miller, Eric Botcazou
Done.
r279003.
- David
On Thu, Dec 5, 2019 at 9:33 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> > Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> > output.h to cp-gimplify.c broke AIX.
> >
> > We certainly can add memmodel.h to cp-gimplify.c.
>
> I'd say so. E.g. c-family/c-cppbuiltin.c which also includes output.h
> includes "memmodel.h" and "tm_h.h" in that order for the same reason
> (since r241121).
>
> Jakub
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SPARC build broken
2019-12-05 14:26 ` David Edelsohn
@ 2019-12-05 14:33 ` Jakub Jelinek
2019-12-05 14:40 ` David Edelsohn
0 siblings, 1 reply; 13+ messages in thread
From: Jakub Jelinek @ 2019-12-05 14:33 UTC (permalink / raw)
To: David Edelsohn; +Cc: Joseph Myers, GCC Patches, David Miller, Eric Botcazou
On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> output.h to cp-gimplify.c broke AIX.
>
> We certainly can add memmodel.h to cp-gimplify.c.
I'd say so. E.g. c-family/c-cppbuiltin.c which also includes output.h
includes "memmodel.h" and "tm_h.h" in that order for the same reason
(since r241121).
Jakub
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SPARC build broken
2019-12-05 13:32 SPARC " Joseph Myers
@ 2019-12-05 14:26 ` David Edelsohn
2019-12-05 14:33 ` Jakub Jelinek
0 siblings, 1 reply; 13+ messages in thread
From: David Edelsohn @ 2019-12-05 14:26 UTC (permalink / raw)
To: Joseph Myers; +Cc: GCC Patches, David Miller, Eric Botcazou, Jakub Jelinek
Sorry. I had to add tm_p.h because Jakub's earlier patch to add
output.h to cp-gimplify.c broke AIX.
We certainly can add memmodel.h to cp-gimplify.c.
Thanks, David
On Thu, Dec 5, 2019 at 8:32 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> The change
>
> 2019-12-04 David Edelsohn <dje.gcc@gmail.com>
>
> * cp-gimplify.c: Include tm_p.h.
>
> appears to have broken the build for SPARC. I see
>
> In file included from ./tm_p.h:4:0,
> from
> /scratch/jmyers/glibc-bot/src/gcc/gcc/cp/cp-gimplify.c:38:
> /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sparc/sparc-protos.h:45:47: error: use of enum 'memmodel' without previous declaration
> extern void sparc_emit_membar_for_model (enum memmodel, int, int);
>
> with my glibc bot. It's possible this declaration ought to be inside
> #ifdef RTX_CODE - that appears to be what other architectures'
> <arch>-protos.h files do with all their declarations using enum memmodel.
>
> https://sourceware.org/ml/libc-testresults/2019-q4/msg00300.html
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* SPARC build broken
@ 2019-12-05 13:32 Joseph Myers
2019-12-05 14:26 ` David Edelsohn
0 siblings, 1 reply; 13+ messages in thread
From: Joseph Myers @ 2019-12-05 13:32 UTC (permalink / raw)
To: gcc-patches, dje.gcc, davem, ebotcazou
The change
2019-12-04 David Edelsohn <dje.gcc@gmail.com>
* cp-gimplify.c: Include tm_p.h.
appears to have broken the build for SPARC. I see
In file included from ./tm_p.h:4:0,
from
/scratch/jmyers/glibc-bot/src/gcc/gcc/cp/cp-gimplify.c:38:
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/sparc/sparc-protos.h:45:47: error: use of enum 'memmodel' without previous declaration
extern void sparc_emit_membar_for_model (enum memmodel, int, int);
with my glibc bot. It's possible this declaration ought to be inside
#ifdef RTX_CODE - that appears to be what other architectures'
<arch>-protos.h files do with all their declarations using enum memmodel.
https://sourceware.org/ml/libc-testresults/2019-q4/msg00300.html
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-12-05 14:40 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-31 21:16 sparc build broken David Miller
2012-05-31 21:42 ` Steven Bosscher
2012-05-31 22:05 ` David Miller
2012-05-31 23:00 ` Steven Bosscher
2012-05-31 23:03 ` David Miller
2012-05-31 23:13 ` Eric Botcazou
2012-06-01 16:02 ` Rainer Orth
2012-06-01 17:51 ` David Miller
2012-06-02 21:52 ` David Miller
2019-12-05 13:32 SPARC " Joseph Myers
2019-12-05 14:26 ` David Edelsohn
2019-12-05 14:33 ` Jakub Jelinek
2019-12-05 14:40 ` David Edelsohn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).