gmane.comp.gcc.devel

gimple type system

Diego has asked me to look into what would be needed in a gimple type 
system.   This is an issue that has been brought to a head because now 
it is time to merge types for lto.

There are a lot of questions that need to be answered before designing 
such a system and i would like to handle them one by one, rather than 
deal with a thousand threads that go off in a lot of directions.  So for 
now, I would like to limit the discussion to a single question:   "what 
do we want to do in the middle end of a compiler with a middle end type 
system?"

I have a couple of positive answers and one negative answer.  The point 
of this mail is to get a more refined list.  The two positive answers are:

1) Type narrowing.   In an object oriented system, it is generally a big 
win to be able to narrow a type as much as possible.   This can be used 
to then be able to inline method calls, as well as remove runtime casts 
and type checks (this is useless for c). 

2) Inter file type checking.  While this is not an optimization, there 
are reasons why it would be useful to discover types that are mismatched 
across compilation units.

The thing that MAY not be useful anymore is the use of a type system of 
alias analysis.   I would have hoped that danny and richi and all of the 
other people hacking on the alias analysis would have subsumed anything 
that one could have gathered from a type based alias analysis.  If I am 
wrong, please correct me. 

Anyway, there must be other uses of types in either the existing middle

(Continue reading)

headers

Richard Guenther | 18 Jul 23:42

Re: gimple type system

On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
<zadeck <at> naturalbridge.com> wrote:
> Diego has asked me to look into what would be needed in a gimple type
> system.   This is an issue that has been brought to a head because now it is
> time to merge types for lto.
>
> There are a lot of questions that need to be answered before designing such
> a system and i would like to handle them one by one, rather than deal with a
> thousand threads that go off in a lot of directions.  So for now, I would
> like to limit the discussion to a single question:   "what do we want to do
> in the middle end of a compiler with a middle end type system?"
>
> I have a couple of positive answers and one negative answer.  The point of
> this mail is to get a more refined list.  The two positive answers are:
>
> 1) Type narrowing.   In an object oriented system, it is generally a big win
> to be able to narrow a type as much as possible.   This can be used to then
> be able to inline method calls, as well as remove runtime casts and type
> checks (this is useless for c).
> 2) Inter file type checking.  While this is not an optimization, there are
> reasons why it would be useful to discover types that are mismatched across
> compilation units.
>
> The thing that MAY not be useful anymore is the use of a type system of
> alias analysis.   I would have hoped that danny and richi and all of the
> other people hacking on the alias analysis would have subsumed anything that
> one could have gathered from a type based alias analysis.  If I am wrong,
> please correct me.

Hah.  You are definitely wrong.

(Continue reading)

headers

Kenneth Zadeck | 19 Jul 00:45

Re: gimple type system

Richard Guenther wrote:
> On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
> <zadeck <at> naturalbridge.com> wrote:
>   
>> Diego has asked me to look into what would be needed in a gimple type
>> system.   This is an issue that has been brought to a head because now it is
>> time to merge types for lto.
>>
>> There are a lot of questions that need to be answered before designing such
>> a system and i would like to handle them one by one, rather than deal with a
>> thousand threads that go off in a lot of directions.  So for now, I would
>> like to limit the discussion to a single question:   "what do we want to do
>> in the middle end of a compiler with a middle end type system?"
>>
>> I have a couple of positive answers and one negative answer.  The point of
>> this mail is to get a more refined list.  The two positive answers are:
>>
>> 1) Type narrowing.   In an object oriented system, it is generally a big win
>> to be able to narrow a type as much as possible.   This can be used to then
>> be able to inline method calls, as well as remove runtime casts and type
>> checks (this is useless for c).
>> 2) Inter file type checking.  While this is not an optimization, there are
>> reasons why it would be useful to discover types that are mismatched across
>> compilation units.
>>
>> The thing that MAY not be useful anymore is the use of a type system of
>> alias analysis.   I would have hoped that danny and richi and all of the
>> other people hacking on the alias analysis would have subsumed anything that
>> one could have gathered from a type based alias analysis.  If I am wrong,
>> please correct me.

(Continue reading)

headers

Richard Guenther | 19 Jul 12:07

Re: gimple type system

On Sat, Jul 19, 2008 at 12:45 AM, Kenneth Zadeck
<zadeck <at> naturalbridge.com> wrote:
> Richard Guenther wrote:
>>
>> On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck
>> <zadeck <at> naturalbridge.com> wrote:
>>
>>>
>>> Diego has asked me to look into what would be needed in a gimple type
>>> system.   This is an issue that has been brought to a head because now it
>>> is
>>> time to merge types for lto.
>>>
>>> There are a lot of questions that need to be answered before designing
>>> such
>>> a system and i would like to handle them one by one, rather than deal
>>> with a
>>> thousand threads that go off in a lot of directions.  So for now, I would
>>> like to limit the discussion to a single question:   "what do we want to
>>> do
>>> in the middle end of a compiler with a middle end type system?"
>>>
>>> I have a couple of positive answers and one negative answer.  The point
>>> of
>>> this mail is to get a more refined list.  The two positive answers are:
>>>
>>> 1) Type narrowing.   In an object oriented system, it is generally a big
>>> win
>>> to be able to narrow a type as much as possible.   This can be used to
>>> then

(Continue reading)

headers

Gaius Mulley | 24 Jul 23:00

Re: gimple type system

Kenneth Zadeck <zadeck <at> naturalbridge.com> writes:

> >> Anyway, there must be other uses of types in either the existing middle end
> >> or that people have dreams of adding to the middle end in the future.   Now
> >> is the time to raise your hand before the design has been started.

Hi,

for me its great use will be to introduce set type debugging into gm2.
At the very minimum it would be nice to be able to define a word sized
bit set which the middle and back end can consider it to have the
properties of "unsigned int" however the debugging info emitted needs
to say that this word is really a set type of some lower and upper
bounds and subtype.

But how this is done via an API is up to you .  My initial thoughts
would be for the front end to be able to define this unsigned int
"fake" type and obtain a unique handle.  The front end would then need
to also maintain the debugging stubs for the type (say dwarf2 and
stabs) which will be invoked by some call back mechanism during the
back end.  But I readily admit this is a little messy..

regards,
Gaius