[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: benchmarks, was Re: toolchain




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 to: