On October 26, 2017 6:47:59 PM GMT+02:00, "Bin.Cheng" <amker.ch...@gmail.com> 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? >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. > >Thanks, >bin