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

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Mark Mitchell writes:

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

	This thread started in the gcc-regressions mailinglist, but the
patch is "Further problems in 32 x 64 builds" in the January 2001
gcc-patches mailinglist.

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

	Oh, cool!  I get to be embarrassed too as I explain this
incorrectly!

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

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

	The patch changes hwint.h to choose HOST_WIDE_INT of the largest
integer type supported by the compiler (e.g., "long long"), not the actual
"natural" width of ints on the host, when the target is wider than the
host.

Mark> - Why does this change cause correctness problems?  

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

	I do not know the root cause of all of the problems, but there are
problems in the rs6000 port which assumes that an int is sign-extended.
Basically, the port is not safe in the face of 64-bit CONST_INT.

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

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

	GCC backend and ports perform more optimizations on CONST_INT than
on CONST_DOUBLE.  If the target is 64-bits and GCC uses HOST_WIDE_INT of
the same size, the resulting code may be better.

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

Mark> It seems that people think the compiler will go slower
Mark> with this change.  Why?

	If the host is a 32-bit system, the "long long" support is
synthesized with multiple instructions.  This slows down the performance
relative to a 64-bit GCC hosted on a native 64-bit platform.  It does make
it more likely that will GCC produce the same code regardless of the host.
    
Mark> - What class of compiler are affected?
  
Mark> Are 32-bit targets affected, or just 64-bit targets?
Mark> Are native compilers affected, or just cross compilers?

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

	Because some targets are runtime selectable between 32-bits and
64-bits, this is not limited to targets of a particular width or
cross-compilers.  Targetting a different width is a subset of a
cross-compiler.  The hwint.h decision depends upon MAX_LONG_TYPE_SIZE
which is the maximum of the runtime selectable values.

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

	Zeroeth order, back out the patch or fix all ports which are not
64-bit H_W_I safe.  First order, determine if imposing 64-bit H_W_I for
64-bit targets really is correct.

	I would love to have the rs6000 port fixed.  I have been examining
this recently and Geoff also investigated this in the past.  Richard and
Mark both would be helped by being able to run the rs6000 port hosted on
64-bit systems.  If we want to make a concerted effort to fix this and
strenuously test it, I will be happy to help.  Fixing the rs6000 port
means destabilizing it, and possibly common parts of the compiler as well.

	Again, IMHO that effort is orthogonal to whether this patch is
correct.  As Alexandre mentioned, his patch does help bring this problem
into the forefront and is a good regression test, but may not be the
correct way to configure 64-bit targets for everyone.  There are a lot of
trade-offs between compile-time performance, runtime performance, and
consistency of output.

David