All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: mike <localgost@gmail.com>
Cc: linux-m68k@vger.kernel.org, debian-68k@lists.debian.org
Subject: Re: benchmarks, was Re: toolchain
Date: Tue, 22 Sep 2009 23:09:19 +1000 (EST)	[thread overview]
Message-ID: <alpine.OSX.2.00.0909222258220.414@silk.local> (raw)
In-Reply-To: <8259f0250909212211l6f4dd00aue3a648f1166ba582@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6411 bytes --]



On Tue, 22 Sep 2009, mike wrote:

> Seems im not the only soul feeling the bloat
> http://news.cnet.com/8301-13505_3-10358024-16.html
> 
> I havent seen any 68k linux benchmarks for this yet
> http://cshandley.co.uk/temp/membench/
> http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14

These benchmarks aren't for linux, right?

> 
> It would be interesting if someone could compare a binary compiled with 
> gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems even. To 
> see if the slowdown has any consistency.

If you would like to run some linux benchmarks, I could build the latest 
kernel using several different compilers for you. I'd need a kernel config 
to suit your hardware though.

But if you want to compare different compilers using benchmarks for a 
different operating system, I can't help with that. You may have more luck 
with that on the relevant mailing list or forum.

Finn

> 
> -Mike
> 
> 
> 2009/9/14  <fthain@telegraphics.com.au>:
> >
> > On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
> >
> >> fthain@telegraphics.com.au wrote:
> >>
> >> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
> >> >
> >> > > Finn Thain wrote: ...
> >> > >
> >> > > > I understand that the current GCC (4.4) lacks the necessary
> >> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
> >> > > > Can someone confirm that this is the necessary patch for 4.4:
> >> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> >> > > I think GCC 4.4 should be good enough.
> >> >
> >> > I tried patching 4.4.1 and the patch was rejected. It expects
> >> > m68k_legitimize_address() to have been declared and defined, but that
> >> > routine isn't in gcc-4.4.
> >>
> >> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
> >> you need to move the hunk to m68k.h.
> >>
> >
> > Thanks for the tip.
> >
> > Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
> > inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
> > m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
> > defined in explow.c so I changed it to HAVE_AS_TLS.
> >
> > It appears to work, but I won't be able to test any binary produced by
> > this compiler for a week or so.
> >
> > Finn
> >
> >
> > --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
> > +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
> > @@ -574,13 +574,7 @@
> >
> >  enum reg_class regno_reg_class[] =
> >  {
> > -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
> > - static void m68k_compute_frame_layout (void);
> > - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
> > - static bool m68k_ok_for_sibcall_p (tree, tree);
> > -+static bool m68k_tls_symbol_p (rtx);
> > - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
> > - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
> > +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
> >  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
> >  static bool m68k_return_in_memory (const_tree, const_tree);
> >  #endif
> > @@ -613,16 +607,6 @@
> >        && crtl->uses_pic_offset_table)
> >      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
> >  }
> > -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
> > - rtx
> > - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
> > - {
> > -+  if (m68k_tls_symbol_p (x))
> > -+    return m68k_legitimize_tls_address (x);
> > -+
> > -   if (GET_CODE (x) == PLUS)
> > -     {
> > -       int ch = (x) != (oldx);
> >  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
> >          && !offset_within_block_p (base, INTVAL (offset)))
> >        return true;
> > @@ -957,7 +941,7 @@
> >        return orig;
> >
> >        gcc_assert (reg);
> > -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
> > +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
> >                                     base == reg ? 0 : reg);
> >
> >        if (GET_CODE (orig) == CONST_INT)
> > @@ -1164,19 +1148,6 @@
> >  +  return orig;
> >  +}
> >  +
> > -+/* Return true if X is a TLS symbol.  */
> > -+
> > -+static bool
> > -+m68k_tls_symbol_p (rtx x)
> > -+{
> > -+  if (!TARGET_HAVE_TLS)
> > -+    return false;
> > -+
> > -+  if (GET_CODE (x) != SYMBOL_REF)
> > -+    return false;
> > -+
> > -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
> > -+}
> >  +
> >  +/* Helper for m68k_tls_referenced_p.  */
> >  +
> > @@ -1414,6 +1385,18 @@
> >
> >  #define REG_OK_FOR_BASE_P(X) \
> >    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
> > +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
> > + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
> > + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
> > + { register int ch = (X) != (OLDX);                                    \
> > +-  if (GET_CODE (X) == PLUS)                                           \
> > ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
> > ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
> > ++    m68k_legitimize_tls_address (X);                                  \
> > ++  else if (GET_CODE (X) == PLUS)                                      \
> > +     { int copied = 0;                                                 \
> > +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
> > +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
> >  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
> >    assemble_name ((FILE), (NAME)),             \
> >    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 

  reply	other threads:[~2009-09-22 13:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31  3:28 bogl: don't know screen type 1 mike
2009-08-31 12:06 ` Stephen R Marenka
2009-08-31 12:58   ` mike
2009-08-31 22:11     ` mike
2009-08-31 22:16       ` mike
2009-09-01 15:17         ` Stephen R Marenka
2009-09-03  1:16           ` mike
2009-09-03  1:22             ` mike
2009-09-03  9:50               ` Maxim Kuvyrkov
2009-09-03 16:41                 ` mike
2009-09-11 20:01               ` Kolbjørn Barmen
2009-09-11 20:25                 ` Geert Uytterhoeven
2009-09-12 10:24                 ` fthain
2009-09-04 15:43           ` toolchain, was " Finn Thain
2009-09-05  1:08             ` Stephen R Marenka
2009-09-05  1:57               ` mike
2009-09-05  2:17                 ` mike
2009-09-05  7:08               ` Petr Stehlik
2009-09-05  8:49               ` Ingo Jürgensmann
2009-09-06  5:07               ` Finn Thain
2009-09-05 13:31             ` Maxim Kuvyrkov
2009-09-05 16:00               ` mike
2009-09-06 10:00                 ` Finn Thain
2009-09-06  2:37               ` toolchain Finn Thain
2009-09-06 23:09                 ` toolchain Stephen R Marenka
2009-09-06  5:20               ` toolchain Finn Thain
2009-09-08 13:07                 ` toolchain Finn Thain
2009-09-13  3:38               ` toolchain, was Re: bogl: don't know screen type 1 fthain
2009-09-13  5:01                 ` Maxim Kuvyrkov
2009-09-14 10:37                   ` fthain
2009-09-22  5:11                     ` mike
2009-09-22 13:09                       ` Finn Thain [this message]
2009-09-22 14:51                         ` benchmarks, was Re: toolchain mike
2009-09-22 15:08                           ` Geert Uytterhoeven
2009-09-28 14:00                       ` toolchain, was Re: bogl: don't know screen type 1 mike
2009-09-28 14:26                         ` debian installation Finn Thain
2009-09-28 14:44                           ` mike
2009-09-29  9:45                             ` mike
2009-09-29 22:23                               ` Rolf Anders

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.OSX.2.00.0909222258220.414@silk.local \
    --to=fthain@telegraphics.com.au \
    --cc=debian-68k@lists.debian.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=localgost@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.