This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: tuples merge for GIMPLE_MODIFY_STMT


On Wed, Nov 15, 2006 at 02:08:26PM -0500, Diego Novillo wrote:

*much chatting goes on on irc*

> >The reason I don't have TREE_OPERAND behave like PROTECTED_* currently
> >does is two-fold:
> >	- speed (questionable as you have pointed out)
> >	- I actually like the idea of ICEing if you try to access a tuple
> >	  as a tree.  For one, it makes it a hell of a lot easier to
> >	  spot unconverted trees-- they ICE :).
> >
> Ah, your second reason may be a good one for short term convenience.
> 
> >If you are unconvinced, we could rename all GIMPLE_MODIFY_OPERAND's
> >back to TREE_OPERAND's and have TREE_OPERAND be all knowing.
> >
> >Let me know.
> >
> I don't really like the name 'PROTECTED_'.  Yeah, having GIMPLE_OPERAND 
> and TREE_OPERAND sounds better.

The reason we can't get rid of a PROTECTED_* type macro is because we need
3 TREE_OPERAND variants:

	1. One to access gimple statements (GIMPLE_MODIFY_OPERAND).
	2. One to access traditional trees (TREE_OPERAND).
	3. One to access either one transparently (currently 
	   PROTECTED_TREE_OPERAND, but you can suggest any name you want--
	   perhaps TRANSPARENT_TREE_OPERAND??).

We need TREE_OPERAND (#2) to ICE when given a gimple statement.  It's
the only way we can nail down all invalid accesses of gimple statements
as trees.  Then we need to provide an accessor (PROTECTED_TREE_OPERAND??)
for when we are sure either a gimple statement *or* a traditional tree
is the source operand-- or actually when we don't know and this ambiguity
is intended.

I'm hesitant to make TREE_OPERAND all knowing, handling both gimple statements
and trees transparently, as it would make it virtually impossible to convert
all the non obvious cases.  It would also make us sloppy.  I'm sure everyone
will just use TREE_OPERAND.

If you are still unconvinced, I am willing to get rid of
GIMPLE_MODIFY_OPERAND in favor of just using one all knowing macro:
TREE_OPERAND.  It would certainly make my life a LOT easier, at the expense
of one more conditional in the macro.  Perhaps this is the best approach:
less changes, one more conditional, less work, more beer.

I'm all ears; let me know.

Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]