This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: GIMPLE tuples. Design and implementation proposal
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 10 Apr 2007 12:25:33 -0400
- Subject: Re: RFC: GIMPLE tuples. Design and implementation proposal
- References: <461B175A.1050407@redhat.com>
On Tue, 2007-04-10 at 00:49 -0400, Diego Novillo wrote:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the implementation going, but there will be
> many details that still need to be addressed.
>
> Thoughts/comments on the proposal?
As I mentioned earlier, I suspect that promoting subcodes to primary
codes carries enough of a penalty that its unlikely to be a good idea
most of the time. As long as the interface routines hide all these
accesses its cheap enough to experiment with tho.
I also think 16 bits for a subcode is excessive, and if some of the
primary opcodes are already planning to use this field as flags, perhaps
we should make that part of the design right from the start. It wont
look like a hack later :-)
Primary opcodes should start numbering their subcodes at 0, and I would
think 8 bits would be more than enough for some time. You can then
reserve/label the other 8 bits as flags. At least as a starting point,
do something along those lines.
Andrew