public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Andi Kleen <andi@firstfloor.org>
Cc: Richard Earnshaw <rearnsha@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"hubicka@ucw.cz" <hubicka@ucw.cz>
Subject: Re: [PATCH] Fix handling of very long asm statements in inliner
Date: Thu, 21 Feb 2013 17:46:00 -0000	[thread overview]
Message-ID: <20130221174627.GA13309@kam.mff.cuni.cz> (raw)
In-Reply-To: <20130221170206.GH2928@two.firstfloor.org>

> > This was not for jump shortening, but the inliner heuristics.
> > 
> > In the worst case we could separate the two, would be a larger
> > patch though.
> 
> Actually it's already separated, I don't affect the jump shortening
> at all. Only the inliner code adds the limit.
> 
> So it would depend whether 1000 * weight is large enough for inlining.
> Honza?

I think it is safely more than enough. 1000*weight makes the function safely
uninlinable. So only it cuts of precision in large function growth/large unit
growth logic.  The logic is skewed here: large function growth is there really
for compiler visible code to prevent non-linear algorithm explosion.  For large
unit growth I duno - in a way those gigantic asm statements that are not going
to be duplicated can be tought as not part of the unit for this putpose, too.

So I am fine with the cutoff.  We may need to add more overflow guards (we
already have quite few for time) that makes me wonder if all this should not be
done all in saturating arithmetic now when it can be done theoretically with one
C++ class?

Honza
> 
> -Andi

  reply	other threads:[~2013-02-21 17:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21 14:06 Andi Kleen
2013-02-21 14:58 ` Richard Earnshaw
2013-02-21 15:59   ` Andi Kleen
2013-02-21 17:02     ` Andi Kleen
2013-02-21 17:46       ` Jan Hubicka [this message]
2013-02-21 18:19         ` Andi Kleen
2013-02-22  3:32           ` Andi Kleen
2013-02-21 18:19     ` Richard Earnshaw
2013-09-08 19:50 ` *PING* " Andi Kleen
2013-09-08 23:23   ` Jan Hubicka

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=20130221174627.GA13309@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=andi@firstfloor.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rearnsha@arm.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 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).