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: [tuples] Tuples accessors patch


On 6/18/07 6:47 PM, Aldy Hernandez wrote:

> Diego, I don't mind all the gs_*_set_* inline functions, I assume it was
> your idea ;-), but should we not also provide  gs_set_code() and
> gs_set_subcode_flags() as well?  I don't know; what do you think?

Yes, I would rather use that than "MACRO (x) = ...".  This change is
actually in my local tree together with a few others that I noticed
after this patch went in.

Chris, you can just make the fixes Aldy suggests here and send a new
patch.  I needed your main patch in the branch so I can start using
these in my changes (I wasn't too concerned with the finer details).

One thing that I'm still a bit undecided is how to deal with accessors
to assignments with binary RHS.  Right now we have separate accessors
for RHS1 and RHS2.  Would it be better to have one accessor with a flag
that specifies which one?  Or would you folks find the different names
easier?

>> +/* Construct a GS_PHI statement, with a CAPACITY, a RESULT, and NARGS
>> +   phi_arg_d * arguments from ...  */
> 
> Can you describe what the arguments are, not just with their names?  If
> you don't know, just leave them out of the description.

Actually, we want to describe *all* the arguments :)

>> -  tree default_label;
>>   tree GTY ((length ("%h.nlabels + 1"))) labels[1];
> 
> Why did we decide to put default_label in the op[] array?  Don't we
> always have a default label?

Which will be labels[0].  Otherwise we are wasting a word out of this
structure.  labels[0] is *always* allocated after all.


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