Lowering of types?

Lowering of types?

[Richard Guenther]

Hi!

During type checking of the middle-end in the tree-optimizers
we run into type mismatches like

fold_binary (code=PLUS_EXPR, type=0x4037e438,
    op0=0x404a6940, op1=0x404a6d40)

with the types

(gdb) call debug_tree (type)
 <integer_type 0x4037e438 gcov_position_t sizes-gimplified asm_written
public unsigned SI
    size <integer_cst 0x40142408 type <integer_type 0x4014a288
bit_size_type> constant invariant 32>
    unit size <integer_cst 0x40142198 type <integer_type 0x4014a21c
unsigned int> constant invariant 4>
    align 32 symtab 1077408160 alias set -1 precision 32 min <integer_cst
0x40142480 0> max <integer_cst 0x40142468 4294967295>>

(gdb) call debug_tree (op0)
 <ssa_name 0x404a6940
    type <integer_type 0x4037e438 gcov_position_t sizes-gimplified
asm_written public unsigned SI
        size <integer_cst 0x40142408 constant invariant 32>
        unit size <integer_cst 0x40142198 constant invariant 4>
        align 32 symtab 1077408160 alias set -1 precision 32 min
<integer_cst 0x40142480 0> max <integer_cst 0x40142468 4294967295>>
    visited var <var_decl 0x403be21c D.5122> def_stmt <modify_expr
0x403bc57c>
    version 19>
(gdb) call debug_tree (op1)
 <ssa_name 0x404a6d40
    type <integer_type 0x4014a57c unsigned int sizes-gimplified
asm_written public unsigned SI
        size <integer_cst 0x40142408 constant invariant 32>
        unit size <integer_cst 0x40142198 constant invariant 4>
        align 32 symtab 1075589640 alias set -1 precision 32 min
<integer_cst 0x40142480 0> max <integer_cst 0x40142468 4294967295>
        pointer_to_this <pointer_type 0x402b93cc>>
    visited var <var_decl 0x403be0d8 D.5119> def_stmt <modify_expr
0x403bc4ec>
    version 5>

which do not match, but still only differ in "name" -- so the
question is can we / do we want to lower types like gcov_position_t
to their (correctly qualified) main variant (or whatever else is
suitable) f.i. during gimplification to allow the optimizers create
strictly typed trees?

Richard.

Re: Lowering of types?

[Richard Henderson]

On Thu, Jun 02, 2005 at 11:21:31AM +0200, Richard Guenther wrote:
> During type checking of the middle-end in the tree-optimizers
> we run into type mismatches like

This isn't a type mismatch if the compatible_p langhook says
they aren't.  Which I expect is true.

> question is can we / do we want to lower types like gcov_position_t
> to their (correctly qualified) main variant (or whatever else is
> suitable) f.i. during gimplification to allow the optimizers create
> strictly typed trees?

I wouldn't think so, no.


r~

Re: Lowering of types?

[Richard Guenther]

On 6/2/05, Richard Henderson <rth@redhat.com> wrote:
> On Thu, Jun 02, 2005 at 11:21:31AM +0200, Richard Guenther wrote:
> > During type checking of the middle-end in the tree-optimizers
> > we run into type mismatches like
> 
> This isn't a type mismatch if the compatible_p langhook says
> they aren't.  Which I expect is true.

What exactly does it mean to the middle-end, if the compatible_p
langhook says true?  Does it mean if the middle-end exchanges one
type for the other there should be no observable effects (correctness
wise) down the road?

Thanks for clarifying,
Richard.

Re: Lowering of types?

[Richard Henderson]

On Thu, Jun 02, 2005 at 08:46:25PM +0200, Richard Guenther wrote:
> Does it mean if the middle-end exchanges one
> type for the other there should be no observable effects (correctness
> wise) down the road?

Yes.


r~

Re: Lowering of types?

[Geoffrey Keating]

Richard Guenther <richard.guenther@gmail.com> writes:

> On 6/2/05, Richard Henderson <rth@redhat.com> wrote:
> > On Thu, Jun 02, 2005 at 11:21:31AM +0200, Richard Guenther wrote:
> > > During type checking of the middle-end in the tree-optimizers
> > > we run into type mismatches like
> > 
> > This isn't a type mismatch if the compatible_p langhook says
> > they aren't.  Which I expect is true.
> 
> What exactly does it mean to the middle-end, if the compatible_p
> langhook says true?  Does it mean if the middle-end exchanges one
> type for the other there should be no observable effects (correctness
> wise) down the road?

If the middle-end exchanges values of one type for the other there
should be no problems.  Swapping the actual types could cause
problems, for instance if you replace a complete structure with an
incomplete version.