On Mon, Oct 8, 2012 at 9:55 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Robert Dewar <de...@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.
