Re: patch to fix constant math

[Richard Sandiford <rdsandiford@googlemail.com>]

Robert Dewar <dewar@adacore.com> writes:
> On 10/8/2012 11:01 AM, Nathan Froyd wrote:
>> ----- Original Message -----
>>> Btw, as for Richards idea of conditionally placing the length field
>>> in
>>> rtx_def looks like overkill to me.  These days we'd merely want to
>>> optimize for 64bit hosts, thus unconditionally adding a 32 bit
>>> field to rtx_def looks ok to me (you can wrap that inside a union to
>>> allow both descriptive names and eventual different use - see what
>>> I've done to tree_base)
>>
>> IMHO, unconditionally adding that field isn't "optimize for 64-bit
>> hosts", but "gratuitously make one of the major compiler data
>> structures bigger on 32-bit hosts".  Not everybody can cross-compile
>> from a 64-bit host.  And even those people who can don't necessarily
>> want to.  Please try to consider what's best for all the people who
>> use GCC, not just the cases you happen to be working with every day.
>
> I think that's rasonable in general, but as time goes on, and every
> $300 laptop is 64-bit capable, one should not go TOO far out of the
> way trying to make sure we can compile everything on a 32-bit machine.

It's not 64-bit machine vs. 32-bit machine.  It's an LP64 ABI vs.
an ILP32 ABI.  HJ & co. have put considerable effort into developing
the x32 ABI for x86_64 precisely because ILP32 is still useful for
64-bit machines.  Just as it was for MIPS when SGI invented n32
(which is still useful now).  I believe 64-bit SPARC has a similar
thing, and no doubt other architectures do too.

After all, there shouldn't be much need for more than 2GB of virtual
address space in an AVR cross compiler.  So why pay the cache penalty
of 64-bit pointers and longs (GCC generally tries to avoid using "long"
directly) when a 32-bit pointer will do?

Many years ago, I moved the HOST_WIDE_INT fields out of rtunion
and into the main rtx_def union because it produced a significant
speed-up on n32 IRIX.  That was before tree-level optimisation,
but I don't think we've really pruned that much RTL optimisation
since then, so I'd be surprised if much has changed.

Richard