On Tue, Nov 7, 2017 at 4:55 PM, Michael Matz <m...@suse.de> wrote:
> 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.
Not sure how - the issue is the FIELD_DECLs overlap which rules out
a RECORD_TYPE and leaves us with a UNION_TYPE. The only other
possibility is not create an aggegate for the equivalence at all but
always access the underlying object via BIT_FIELD_REFs (hopefully
the offsets of the fields are always compile-time known constants?).
Richard.
>
> Ciao,
> Michael.
