public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Andrew MacLeod <amacleod@redhat.com>,
	Ian Lance Taylor <iant@google.com>,
	        gcc-patches@gcc.gnu.org
Subject: Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables
Date: Wed, 03 Jun 2009 17:43:00 -0000	[thread overview]
Message-ID: <oriqjdkybk.fsf@free.oliva.athome.lsd.ic.unicamp.br> (raw)
In-Reply-To: <84fc9c000906030318i9e3f0dfx3735490450f2875e@mail.gmail.com> (Richard Guenther's message of "Wed\, 3 Jun 2009 12\:18\:43 +0200")

On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> On Wed, Jun 3, 2009 at 3:13 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
>> I think we are simply proposing that when VTA code is added and enabled, the
>> default behaviour is then changed such that we do this coalescing.  Until
>> then it stays with the current tradeoffs. no options required...

> Right, this is what I would suggest as well.

Hmm...  That's a “wilder” path than the incremental one I had in mind.

I wasn't thinking VTA would have been enabled by default right away.
Even if it was, I think it would be important to retain a possibility to
turn it off, at least until it's proven on more ports than the testing
it got so far.

And then, if VTA can be turned on or off, other trade-offs (like this
one), that work better with VTA but worse without it, should be
controllable too.

And then, there's the factor of being able to measure the impact of the
changes.  If we support the options, we can simply compare one with the
other, using the very same compiler.  If we don't, at the very least
we'd have to maintain patches that revert to past behavior, or that
advance to future behavior, build more toolchains and compare compiler
output like that.

This was my reasoning to implement the proposed options.  They're useful
on their own right now, regardless of VTA.  One of them can bring about
significant compile-time and run-time improvements, whereas the other
can bring about slightly better debug information.  With or without VTA.

Sure enough, if VTA goes in and becomes default and can't be disabled,
the options cease to make much sense.  We can remove them then, when and
if it happens.  But since so far there's no indication that VTA is
actually going in, rejecting this patch on the grounds of an unwarranted
assumption comes off as very odd to me.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

  reply	other threads:[~2009-06-03 17:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01 19:05 Alexandre Oliva
2007-10-02  9:15 ` Richard Guenther
2007-10-02 21:02 ` Andrew MacLeod
2007-10-03  1:11   ` Alexandre Oliva
2007-10-09 21:32     ` Alexandre Oliva
2009-06-01  7:39       ` [trunk<-vta] " Alexandre Oliva
2009-06-01  7:44         ` Alexandre Oliva
2009-06-01 16:11         ` Ian Lance Taylor
2009-06-01 17:35           ` Andrew MacLeod
2009-06-01 19:23             ` Alexandre Oliva
2009-06-02  9:54               ` Richard Guenther
2009-06-02 21:42                 ` Alexandre Oliva
2009-06-03  1:13                   ` Andrew MacLeod
2009-06-03 10:18                     ` Richard Guenther
2009-06-03 17:43                       ` Alexandre Oliva [this message]
2009-06-03 18:06                         ` Daniel Jacobowitz
2009-06-03 19:17                           ` Alexandre Oliva
2009-06-03 19:45                             ` Daniel Jacobowitz
2009-06-03 21:42                               ` Alexandre Oliva
2009-06-03 18:18                         ` Richard Guenther
2009-06-03 19:15                           ` Alexandre Oliva
2009-06-03 19:50                             ` Richard Guenther
2009-06-03 19:53                               ` Ian Lance Taylor
2009-10-13 21:27         ` Alexandre Oliva
2011-06-04 12:45           ` Alexandre Oliva
2011-06-04 13:02             ` Jakub Jelinek
2011-06-05 21:07               ` Alexandre Oliva
2011-06-06  2:42                 ` Alexandre Oliva
2012-04-09  5:56             ` Alexandre Oliva
2012-06-13  8:34               ` Alexandre Oliva
2012-06-13  9:48                 ` Richard Guenther

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=oriqjdkybk.fsf@free.oliva.athome.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=richard.guenther@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 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).