On Thu, Aug 16, 2012 at 10:21 AM, Michael Matz <m...@suse.de> wrote:
> Hi,
>
> On Thu, 16 Aug 2012, Diego Novillo wrote:
>
>> I like this approach, particularly since it would be used in contexts
>> where there is no simpler scheme.  I'm not crazy about overloading
>> unused fields, but it's fine if we wrap it around a special accessor. I
>> suppose we could also make ENTRY/EXIT be a base class for basic_block
>> and use a real field (but that can wait).
>
> Actually the other way around (ENTRY/EXIT be a subclass), as it would be

Yeah, sorry.

> an additional field to the normal basic blocks.  But for central data
> structures I'm usually of the opinion that jumping through hoops just to
> not enlarge them is quite acceptable :)

Yeah, adding a full word when it's only used in a few places does not
seem like a good tradeoff.

>> There are other pieces of data that are "global" but context-dependent.
>> I wonder if it wouldn't make sense to encapsulate them in some class
>> that is controlled by the pass manager and gets updated as it moves from
>> function to function (it would contain things like cfun,
>> current_function_decl, etc).
>
> And on that topic: I think it makes sense to eventually get rid of one or
> the other, current_function_decl is always (well, mostly) cfun->decl, if
> cfun happens to be set.  I know there are some roadblocks in front of that
> goal, but still.

Agreed.


Diego.

Reply via email to