All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
To: Bernd Schmidt <bernds_cb1@t-online.de>
Cc: Sam Ravnborg <sam@ravnborg.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS
Date: Mon, 12 Nov 2007 17:40:23 +0100	[thread overview]
Message-ID: <20071112164023.GL9771@stusta.de> (raw)
In-Reply-To: <47387E32.4050206@t-online.de>

On Mon, Nov 12, 2007 at 05:24:18PM +0100, Bernd Schmidt wrote:
> Adrian Bunk wrote:
> > The gcc from svn that will become gcc 4.3 generates libgcc calls in 
> > cases like the following (on 32bit architectures):
> > 
> > <--  snip  -->
> > 
> > static inline void timespec_add_ns(struct timespec *a, u64 ns)
> > {
> > ...
> >         while(ns >= NSEC_PER_SEC) {
> >                 ns -= NSEC_PER_SEC;
> >                 a->tv_sec++;
> >         }
> > ...
> > 
> > <--  snip  -->
> > 
> > It can make sense to emit assembler code doing division for such C code -
> > that doesn't seem to be something that would generally be wrong.
> 
> It can be a pretty huge performance regression, so gcc ought to be fixed.

What is better depends on the values of ns and NSEC_PER_SEC.

It can be a performance regression, but there are also cases where it 
can improve performance. If gcc produces lower performance code that
would be a bug in gcc that should be reported, but using a division is 
not generally wrong.

A more clearer example might be:

<--  snip  -->

void foo(u64 ns)
{
	if (ns < 10000)
		return;

	while(ns >= 3) {
		ns -= 3;
#ifdef DEBUG
		bar(ns);
#endif
	}
}

<--  snip  -->

With DEBUG not defined you can hardly argue gcc should be fixed to not 
use a division for performance reasons.

> Bernd

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2007-11-12 16:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-11  6:48 [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS Adrian Bunk
2007-11-11  7:34 ` Paul Mundt
2007-11-12  6:14   ` the kernel, gcc and libgcc Adrian Bunk
2007-11-12 16:24 ` [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS Bernd Schmidt
2007-11-12 16:40   ` Adrian Bunk [this message]
2007-11-12 22:07     ` Bernd Schmidt
2007-11-13  6:04       ` Adrian Bunk
2007-11-12 16:58 ` Jakub Jelinek
2007-11-13 11:39   ` Adrian Bunk

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=20071112164023.GL9771@stusta.de \
    --to=bunk@kernel.org \
    --cc=bernds_cb1@t-online.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /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.