This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.



	  This patch isn't even an optimization, it is a trade-off.

I somehow missed a lot of this thread, and can't find where it all
comes from in the archives.

At the risk of embarassing myself, I'd like some help understanding
what's going on.  David E., I think you'd be a good person to
summarize; perhaps you could answer the following questions.  (If
others disagree with David's answers, then we can debate that.)

  - What is the purpose of the change?  (Equivalently, what are
    it's benefits?)

    For example, it seems to me that if we only have 2 32-bit values
    to represent an integer, then we can't do 128-bit target
    arithmetic, so I could see that justifying using 2 64-bit values
    instead, on the host.  But, anyhow, I'd just like a summary of
    what the win is.

  - Why does this change cause correctness problems?  

    I tried to read some of the mail, and couldn't figure it out.
    For example, do back-ends make explicit assumptions about how
    many bits are in a HOST_WIDE_INT?  Do they assume that left-shifts
    will cause high-order bits to "disappear", but now they don't
    because the types are wider?  What are the correctness problems?

  - What run-time performance problems does this change cause?

    It seems that people think the generated code will go slower
    with this change.  Why?

  - What compile-time performance problems does this change cause?

    It seems that people think the compiler will go slower
    with this change.  Why?
    
  - What class of compiler are affected?
  
    Are 32-bit targets affected, or just 64-bit targets?
    Are native compilers affected, or just cross compilers?

    For example, is a x86 GNU/Linux native compiler affected?  Or
    only a x86 GNU/Linux hosted compiler targeting an IA64 target?
    Or what?

Let's just get these facts on the table, with as little opinion as
possible.  Now, with a little bit more opinion:

  - What solutions are conceptually possible, other than backing out
    the patch?

    Is this something that can be enabled on a target-by-target basis,
    and only enabled for now on targets that know they want it?  (So
    that even if we think this is the right way to go long term we
    can avoid destabilizing in the short term?)  

I think that given:

  I can't promise to fix all problems on all 64-bit targets.

that's evidence towards backing out the patch.  The normal ethic
behind check-ins is that you will work to fix all problems with your
patch -- with the understanding, of course, that interested parties
will help you track things down, etc., and that your patch may
actually reveal latent bugs elsewhere, that might end up being someone
else's responsibility to fix.  (That's why it's "safer" to be a C++
hacker, or a HPUX hacker, than a optimizer hacker; changes in the
former areas don't affect as much stuff as changes in the latter.)

But, all that aside, I think that if we can get more information some
combination of I/SC can make an appropriate decision.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]