On Tue, Nov 25, 2014 at 2:06 AM, Joseph Myers wrote:
> On Mon, 24 Nov 2014, Richard Biener wrote:
>
>> > TREE_LIST should die (with the typical replacement being vec);
>> > most lists do not need all the overhead of individually allocated objects
>> > with (code, flags, type, chain, value, purpose
On Mon, 24 Nov 2014, Richard Biener wrote:
> > TREE_LIST should die (with the typical replacement being vec);
> > most lists do not need all the overhead of individually allocated objects
> > with (code, flags, type, chain, value, purpose). Probably TREE_VEC too.
>
> Note that there is nothing w
On Sat, Nov 22, 2014 at 12:49 AM, Joseph Myers wrote:
> On Fri, 21 Nov 2014, Andrew MacLeod wrote:
>
>> The biggest issue is what to do with fields which can be either a type or a
>> tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a TREE_VEC
>> element or a DECL_CONTEXT. I think
On Fri, 21 Nov 2014, Andrew MacLeod wrote:
> The biggest issue is what to do with fields which can be either a type or a
> tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a TREE_VEC
> element or a DECL_CONTEXT. I think the DECL_INITIAL field is overloaded and
> can sometimes be a
On Fri, 2014-11-21 at 21:13 +0100, Richard Biener wrote:
> On November 21, 2014 8:45:09 PM CET, Diego Novillo
> wrote:
> >On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod
> >wrote:
> >
> >> 1 - introduce a TYPE_REF tree node, which is effectively just a
> >'typed' tree
> >> node, and the TREE_TYPE
On 11/21/2014 05:39 PM, Jeff Law wrote:
On 11/21/14 11:48, Andrew MacLeod wrote:
There are a few issues, of course :-)
The biggest issue is what to do with fields which can be either a type
or a tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a
TREE_VEC element or a DECL_CONT
On 11/21/14 11:48, Andrew MacLeod wrote:
There are a few issues, of course :-)
The biggest issue is what to do with fields which can be either a type
or a tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a
TREE_VEC element or a DECL_CONTEXT. I think the DECL_INITIAL field is
o
On November 21, 2014 9:22:08 PM CET, Andrew MacLeod wrote:
>On 11/21/2014 03:13 PM, Richard Biener wrote:
>> On November 21, 2014 8:45:09 PM CET, Diego Novillo
> wrote:
>>> On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod
>
>>> wrote:
>>>
1 - introduce a TYPE_REF tree node, which is effectivel
On 11/21/2014 03:13 PM, Richard Biener wrote:
On November 21, 2014 8:45:09 PM CET, Diego Novillo wrote:
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod
wrote:
1 - introduce a TYPE_REF tree node, which is effectively just a
'typed' tree
node, and the TREE_TYPE() field of a TYPE_REF node wou
On 11/21/2014 02:45 PM, Diego Novillo wrote:
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod wrote:
1 - introduce a TYPE_REF tree node, which is effectively just a 'typed' tree
node, and the TREE_TYPE() field of a TYPE_REF node would point to the type
node. Any routines which utilize a TYPE n
On November 21, 2014 8:45:09 PM CET, Diego Novillo wrote:
>On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod
>wrote:
>
>> 1 - introduce a TYPE_REF tree node, which is effectively just a
>'typed' tree
>> node, and the TREE_TYPE() field of a TYPE_REF node would point to the
>type
>> node. Any routin
On Fri, Nov 21, 2014 at 1:48 PM, Andrew MacLeod wrote:
> 1 - introduce a TYPE_REF tree node, which is effectively just a 'typed' tree
> node, and the TREE_TYPE() field of a TYPE_REF node would point to the type
> node. Any routines which utilize a TYPE node in a tree list would have to
> be modi
12 matches
Mail list logo
