Re: patch to fix constant math

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Oct 8, 2012 at 9:55 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> 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 of course that doesn't change the alignment requirement of
that union which is the issue on lp64 hosts.  Also as HOST_WIDE_INT
is 64bits for most ilp32 targets as well it doesn't necessarily save
ilp32 hosts from having this issue (unless long long isn't aligned
to 8 bytes for them).  So what I said is that arranging for the 32bit
hole to contain useful data for most RTXen should be possible.

Richard.

> but I don't think we've really pruned that much RTL optimisation
> since then, so I'd be surprised if much has changed.