Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Guenther]

On 7/12/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:

As was discussed at the summit, we'd like to get rid of global language
callbacks so that we can
safely inline from different source languages.
AFAICS, this can be archived by using the space occupied by the
lang_flags to store a language
tag in each tree node.
I.e., while the frontend does processes the source, we use the language
hook from that frontend,
but once everything is converted to GIMPLE, each tree node is tagged
with the source language,
and language hooks are looked up using this language hook in the tree
node that defines the context
for which langiage-specific information is needed.

This assumes that after conversion to GIMPLE, we don't need any more
lang_flags.  Is that true?


I don't understand what you are exactly trying to do, but I guess you
want to "virtualize" the lang-hooks?  The proper way to get rid of them
is to encode the information they provide in the IL, not to encode the
source language in the trees.

Richard.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> I don't understand what you are exactly trying to do, but I guess you
> want to "virtualize" the lang-hooks?  The proper way to get rid of them
> is to encode the information they provide in the IL, not to encode the
> source language in the trees.

I strongly agree and was going to say so in response to the original message.

I think that having language hooks apply to GIMPLE is wrong.  I strongly
believe that the semantics of GIMPLE ought to be defined very precisely and
in a language-independent way.  With the exception of debugging information,
I think this is true for types too: we define what the semantics of types are
independent of any particular language.

For example, I've long felt that calling a lang hook to see if two types are
"compatible" is quite wrong.  That's relevant at the language
syntactic/semantic level of validing such things as parameter lists, but to
GIMPLE two types are compatible if and only if they would produce the
identical RTL.  So two integer types are compatible if they have the same
mode, precision, and bounds.  Two FIELD_DECLs are compatible if they have the
same positions, aligments, sizes, and compatible types, two record types are
compatible if they have the same sizes and alignment and all fields are
compatible.  Etc.

The issue of debugging information is very different but I don't think in
the scope of this particular discussion.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Diego Novillo]

Richard Kenner wrote on 07/12/06 14:33:
>> I don't understand what you are exactly trying to do, but I guess you
>> want to "virtualize" the lang-hooks?  The proper way to get rid of them
>> is to encode the information they provide in the IL, not to encode the
>> source language in the trees.
> 
> I strongly agree and was going to say so in response to the original message.
> 
> I think that having language hooks apply to GIMPLE is wrong.  I strongly
> believe that the semantics of GIMPLE ought to be defined very precisely and
> in a language-independent way.  With the exception of debugging information,
> I think this is true for types too: we define what the semantics of types are
> independent of any particular language.
> 
> For example, I've long felt that calling a lang hook to see if two types are
> "compatible" is quite wrong.  That's relevant at the language
> syntactic/semantic level of validing such things as parameter lists, but to
> GIMPLE two types are compatible if and only if they would produce the
> identical RTL.  So two integer types are compatible if they have the same
> mode, precision, and bounds.  Two FIELD_DECLs are compatible if they have the
> same positions, aligments, sizes, and compatible types, two record types are
> compatible if they have the same sizes and alignment and all fields are
> compatible.  Etc.
> 
> The issue of debugging information is very different but I don't think in
> the scope of this particular discussion.
>
Yup.  That's been the idea all along.  We represent all the FE language
semantics in GIMPLE, much like we expose ctor/dtor in C++ or EH or any
of the other language mechanisms.

Everything must be explicitly represented in the IL, totally independent
from the input language.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Diego Novillo wrote:
> That's relevant at the language
>> syntactic/semantic level of validing such things as parameter lists, but to
>> GIMPLE two types are compatible if and only if they would produce the
>> identical RTL.  So two integer types are compatible if they have the same
>> mode, precision, and bounds.  Two FIELD_DECLs are compatible if they have the
>> same positions, aligments, sizes, and compatible types, two record types are
>> compatible if they have the same sizes and alignment and all fields are
>> compatible.  Etc.
>>
>> The issue of debugging information is very different but I don't think in
>> the scope of this particular discussion.
>>
> Yup.  That's been the idea all along.  We represent all the FE language
> semantics in GIMPLE, much like we expose ctor/dtor in C++ or EH or any
> of the other language mechanisms.
> 
> Everything must be explicitly represented in the IL, totally independent
> from the input language.

FWIW, I agree.  However, I do not agree that two types are compatible
iff they would produce identical RTL.  GIMPLE should still know that
"int" and "long" are distinct types (even if both 32 bits) since that
permits alias analysis to do a better job.  Similarly, "struct S { int
i; }" and "struct T {int j; }" are not the same type.

So, what should happen is that the front end should make these
differences/similarities visible to the middle end via TYPE_ALIAS_SET,
or some other mechanism *in the IL itself* rather than via a callback.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> FWIW, I agree.  However, I do not agree that two types are compatible
> iff they would produce identical RTL.  GIMPLE should still know that
> "int" and "long" are distinct types (even if both 32 bits) since that
> permits alias analysis to do a better job.

Sure, but that's not what we currently use the compatible types hook for.
What you're essentially saying is that (int *) and (long *) are different
types, and that's correct.  But if we have a cast from "int" to "long"
or vice versa, that cast is not accomplishing anything and *could* be
deleted.

> Similarly, "struct S { int
> i; }" and "struct T {int j; }" are not the same type.

Likewise.  (struct T *) and (struct S *) aren't the same, but a
VIEW_CONVERT_EXPR from struct T to struct S isn't accomplishing anything
and can also be deleted.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Richard Kenner wrote:
>> FWIW, I agree.  However, I do not agree that two types are compatible
>> iff they would produce identical RTL.  GIMPLE should still know that
>> "int" and "long" are distinct types (even if both 32 bits) since that
>> permits alias analysis to do a better job.
> 
> Sure, but that's not what we currently use the compatible types hook for.
> What you're essentially saying is that (int *) and (long *) are different
> types, and that's correct.  But if we have a cast from "int" to "long"
> or vice versa, that cast is not accomplishing anything and *could* be
> deleted.

In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
the type information about the result.  But, I'm not a GIMPLE expert;
maybe there's some magic way of handling this.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
> the type information about the result.  But, I'm not a GIMPLE expert;
> maybe there's some magic way of handling this.

The type of the "result" is always the type of the LHS.  Nothing would
be changing that.  And if you take the address of something, the type
of the ADDR_EXPR is the pointer type.  So I don't understand what you
mean here.  The alias set comes from the INDIRECT_REF or decl, not any
other node.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Richard Kenner wrote:
>> In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
>> the type information about the result.  But, I'm not a GIMPLE expert;
>> maybe there's some magic way of handling this.
> 
> The type of the "result" is always the type of the LHS. 

OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that "int = long" would be well-formed gimple.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
> that "int = long" would be well-formed gimple.

I thought that "type safe" meant *compatible* types ...

Re: RFD: language hooks in GIMPLE / lang_flag?

[Andrew Pinski]

On Jul 15, 2006, at 1:12 PM, Mark Mitchell wrote:

OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that "int = long" would be well-formed gimple.


Right now it is for 32bit targets because of  
tree_ssa_useless_type_conversion_1's:

  /* If both the inner and outer types are integral types, then the
 conversion is not necessary if they have the same mode and
 signedness and precision, and both or neither are boolean.  Some
 code assumes an invariant that boolean types stay boolean and do
 not become 1-bit bit-field types.  Note that types with precision
 not using all bits of the mode (such as bit-field types in C)
 mean that testing of precision is necessary.  */
  else if (INTEGRAL_TYPE_P (inner_type)
   && INTEGRAL_TYPE_P (outer_type)
   && TYPE_UNSIGNED (inner_type) == TYPE_UNSIGNED (outer_type)
   && TYPE_PRECISION (inner_type) == TYPE_PRECISION  
(outer_type)
   && simple_cst_equal (TYPE_MAX_VALUE (inner_type),  
TYPE_MAX_VALUE (outer_type))
   && simple_cst_equal (TYPE_MIN_VALUE (inner_type),  
TYPE_MIN_VALUE (outer_type)))



Even right now we allow "int* = void*" without a cast.  I posted a patch
to fix that up at 

which I am still waiting for approval for.

Thanks,
Andrew Pinski

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
> that "int = long" would be well-formed gimple.

... or we *could* define it that way.

My point is just that whatever type "compatibility" might mean at the
GIMPLE level, it should just be a function of whether the types will produce
different code, not something at the language level.  The qustion of what
we use the compatible types test for is different.  I wasn't suggesting
(at this point at least!) that it be changed, but didn't research exactly
when it's used either.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Guenther]

On 7/15/06, Richard Kenner <[EMAIL PROTECTED]> wrote:

> OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
> that "int = long" would be well-formed gimple.

... or we *could* define it that way.

My point is just that whatever type "compatibility" might mean at the
GIMPLE level, it should just be a function of whether the types will produce
different code, not something at the language level.  The qustion of what
we use the compatible types test for is different.  I wasn't suggesting
(at this point at least!) that it be changed, but didn't research exactly
when it's used either.


For most parts of the middle-end treating type compatibility as equivalence
of machine modes (for basic types, that is) should be ok.  Of course to not
lose alias information it needs to be attached to the proper objects (decls
and memory references) by the frontends and propagated accordingly.

Richard.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Michael Matz]

Hi,

On Fri, 14 Jul 2006, Mark Mitchell wrote:

> > Everything must be explicitly represented in the IL, totally 
> > independent from the input language.
> 
> FWIW, I agree.  However, I do not agree that two types are compatible 
> iff they would produce identical RTL.  GIMPLE should still know that 
> "int" and "long" are distinct types (even if both 32 bits) since that 
> permits alias analysis to do a better job.

Disagreement here, but see below.

> Similarly, "struct S { int i; }" and "struct T {int j; }" are not the 
> same type.
> 
> So, what should happen is that the front end should make these 
> differences/similarities visible to the middle end via TYPE_ALIAS_SET, 
> or some other mechanism *in the IL itself* rather than via a callback.

And agreement here :-)  For the purposes of code generated type 
equivalence should be structural equivalence, i.e. if they generate the 
same code they should be treated equivalently.  In fact we should be able 
to do away with types at all at GIMPLE level (at least after LTO dumped 
it's part and read it back), and only retain the scalar simple types.  To 
compensate for this loss of information every appropriate place would need 
to be annotated with an alias number, which completely would specify the 
frontends definition of the alias system, as required by the language.  
Additionally an alias graph would need to be emitted by the frontend, 
refering to those numbers.  Those graphs would need to be merged from 
different modules, and for _that_ purpose there needs to be a mapping to 
the original types.

For purposes of disamiguating accesses inside loops we might need some 
better annotation or mem-access primitives (carrying the indices), but 
even them in the end don't need to know the full base types 
(int/long/fortran INTEGER*4 don't matter, if the width and signedness are 
the same, that would be encoded by the alias set number).

How that aliasing merging takes place can be specified by us in whatever 
way we like.  E.g. just a disjoint union (then all objects/accesses over 
module borders would alias), or some intelligent unification of nodes 
(e.g. based on type structure equivalence, or type name, or whatever).

I think that would very much help the inter language aspect of LTO.  


Ciao,
Michael.