IPA merge part 1: localize SSA variables

Diego Novillo dnovillo@redhat.com
Wed Nov 15 21:10:00 GMT 2006


Jan Hubicka wrote on 11/15/06 15:59:
>> Jan Hubicka wrote on 11/15/06 15:49:
>>
>>> OK, I will use gimple_df then (or some shorter variant?).  What about
>>> the ancestor macros/functions problem?  I
>>>
>> My vote is to qualify all of them with a CFUN argument.  But this will 
>> certainly have repercussions in branches.  Let's see what other 
>> maintainers think.
> 
> I think we settled down that we do want to have accestors.  I meant
> whehter we want to use something like
> 
> #define blah(fun) (fun)->df_gimple->blah
> or
> #define gimple_blah(fun) (fun)->df_gimple->blah
> 
> those might have problems if we want to embed some logic in it (such as
> I do with in_ssa_p now testing whether fun->df_gimple is really nonzero,
> so I can't use it as LHS anymore).  We can follow tree-flow-inline logic
> too:
> inline type
> blah(fun)
> {
>   return (fun)->df_gimple->blah
> }
> inline void
> set_blah(fun,val)
> {
>   fun->df_gimple->blah = val
> }
> alternatively with the gimple_ prefixes or some other variant.
> 
Well, I'm biased.  I kind-of like blah/set_blah, but I think I'm in the 
minority, so I won't push for it.

Regarding the accessor name, might as well prefix them with gimple_



More information about the Gcc-patches mailing list