Re: [tree-ssa] must-alias analysis

[Nathanael Nerode <neroden at twcny dot rr dot com>]

>>No, that does a conversion; *(type*)&VAR does type punning.
>Oh blech.  Of course.
>
>I think we're under no obligation to optimize type punning, as long
>as we don't make it worse than the original code. :-P

Which leads me to the realization that the case we really want this for
is the case where there *isn't* actually any type punning going on; it 
just *looks* like there might be.  The example given seems to be of this 
type:

>struct complex {
>    double re, im;
>    complex(double r, double i) : re(r), im(i) {}
>};
>
>inline complex operator+(const complex& a, const complex& b) {
>    return complex(a.re+b.re, a.im+b.im);
>}
>
>complex addone(const complex& arg) {
>    return arg + complex(1,0);
>}
>
>
>When we inline operator+ into addone, we get code like this:
>
>      struct complex * const this;
>
>      this_2 = (struct complex * const)&<UV770>;
                                        ^^^^^^^^
I'm not at all sure what this is refering to,
but 'arg' is 'const complex&' and we need a 'struct complex * const',
which may be a typecast, but isn't type-punning.

Can we detect this situation (where the typecast isn't type-punning,
but is effectively the same type), and use exactly what I suggested
before in this case?

>      r_3 = 1.0e+0;
>      i_4 = 0.0;
>      {
>        this_2->re = 1.0e+0;
>        this_2->im = 0.0;
>        {
>          (void)0
>        }
>      }


-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html