Hi,
On Thu, 26 Oct 2017, Richard Biener wrote:
> >Hi,
> >I am looking into DSE transformation of some fortran codes. Given
> >below fortran declarations:
> >
> > real*8 a(len) , b(len) , c(len) , d(len)
> > common /area/ a, b, c, d
> > real*8 src1(len), temp1(len), temp2(len), src2(len)
> > equivalence (src1, a), (src2, b), (temp1, c), (temp2, d)
> >
> >with my limited understanding of fortran, the layout should be like:
> >struct area
> >{
> > union {double src1[len]; double a[len]};
> > union {double temp1[len]; double b[len]};
> > union {double temp2[len]; double c[len]};
> > union {double src2[len]; double d[len]};
> >};
>
> I guess equivalence with mismatching size and overlaps makes this a difficult
> representation. Not that such equivalence would be valid...
>
> >When debugging in tree-ssa-dse.c, if I have memory reference like
> >area.src1[idx], the type for area dumped is like:
> >(gdb) call debug_generic_expr(ref1->exp.operands[0])
> >area
> >(gdb) call debug_generic_expr(ref1->exp.operands[0]->typed.type)
> >union
> >{
> > real(kind=8) src1[100];
> > real(kind=8) a[100];
> > real(kind=8) src2[100];
> > real(kind=8) b[100];
> > real(kind=8) temp1[100];
> > real(kind=8) c[100];
> > real(kind=8) temp2[100];
> > real(kind=8) d[100];
> >}
> >I do noticed src1/src2 fields do have different offset, although they
> >are put into a union type here.
>
> It's definitely stretching what I would consider a valid union type.
> Maybe Ada does have similar layouts?
Maybe it's rather an implementation artifact of trying to capture the
effects of the unnamed members (of union type) that are in the struct. In
the end it doesn't matter much for code generation: the field offsets
matter, not if the surrounding type is a union or struct. It's confusing,
though :) (and inhibits optimization that expect only "sane" types).
> >I suppose such type are generated by fortran front-end? Is it just
> >because it's easy to do so? And any background comment/document about
> >this?
> >Unfortunately middle end misses lots of dead store, redundant load
> >because of difficulty in alias check of such type information. I
> >guess fully support alias check of this issue would be non-trivial, so
> >any suggestions will be highly appreciated too.
You can probably change the fortran frontend to create saner types for
this.
Ciao,
Michael.
