Modifying types during optimization

Modifying types during optimization

[Gary Oblock]

I'm working on structure reorganization optimizations and one of the
things that needs to happen is that pointers to arrays of structures
need to be modified into either being an integer of a structure depending
on which optimization is required.

I'm seeing something similar happening in omp-low.c where the code in
install_var_field and fixup_child_record_type both seem to rebuild the
entire type from scratch if a field is either added or modified. Wouldn't
it be possible simply modify the field(s) in question and rerun layout_type?

I suspect the answer will be no but reasons as to why that wouldn't work
will probably be equally valuable to me.

Thanks,

Gary Oblock

Re: Modifying types during optimization

[Richard Biener]

On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock <goblock@marvell.com> wrote:
>
> I'm working on structure reorganization optimizations and one of the
> things that needs to happen is that pointers to arrays of structures
> need to be modified into either being an integer of a structure depending
> on which optimization is required.
>
> I'm seeing something similar happening in omp-low.c where the code in
> install_var_field and fixup_child_record_type both seem to rebuild the
> entire type from scratch if a field is either added or modified. Wouldn't
> it be possible simply modify the field(s) in question and rerun layout_type?
>
> I suspect the answer will be no but reasons as to why that wouldn't work
> will probably be equally valuable to me.

I think it's undesirable at least.  When last discussing "structure reorg"
I was always arguing that trying to change the "type" is the wrong angle
to look at (likewise computing something like "type escape").  It's
really individual objects you are transforming and that you need to track
so there may be very well instances of the original type T plus the
modified type T' in the program after the transform.

Richard.

>
> Thanks,
>
> Gary Oblock
>

Re: [EXT] Re: Modifying types during optimization

[Gary Oblock]

On 10/2/19 3:15 AM, Richard Biener wrote:
> External Email
>
> ----------------------------------------------------------------------
> On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock <goblock@marvell.com> wrote:
>> I'm working on structure reorganization optimizations and one of the
>> things that needs to happen is that pointers to arrays of structures
>> need to be modified into either being an integer of a structure depending
>> on which optimization is required.
>>
>> I'm seeing something similar happening in omp-low.c where the code in
>> install_var_field and fixup_child_record_type both seem to rebuild the
>> entire type from scratch if a field is either added or modified. Wouldn't
>> it be possible simply modify the field(s) in question and rerun layout_type?
>>
>> I suspect the answer will be no but reasons as to why that wouldn't work
>> will probably be equally valuable to me.
> I think it's undesirable at least.  When last discussing "structure reorg"
> I was always arguing that trying to change the "type" is the wrong angle
> to look at (likewise computing something like "type escape").  It's
> really individual objects you are transforming and that you need to track
> so there may be very well instances of the original type T plus the
> modified type T' in the program after the transform.
>
> Richard.
>
>> Thanks,
>>
>> Gary Oblock
>>
I answered Richard privately yesterday but I was wondering if anybody else
had any ideas about modifying type fields. Note, I agreed with Richard
and assured
him I was already planning to do things that way but I still don't see
any reason
why rebuilding a type (it's clone of the other type) is better than
modifying it.
I take my inspiration for relayout_decl and just want to create what in
essence would
be a relayout_type.

Gary

Re: [EXT] Re: Modifying types during optimization

[Richard Biener]

On Wed, Oct 2, 2019 at 8:50 PM Gary Oblock <goblock@marvell.com> wrote:
>
> On 10/2/19 3:15 AM, Richard Biener wrote:
> > External Email
> >
> > ----------------------------------------------------------------------
> > On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock <goblock@marvell.com> wrote:
> >> I'm working on structure reorganization optimizations and one of the
> >> things that needs to happen is that pointers to arrays of structures
> >> need to be modified into either being an integer of a structure depending
> >> on which optimization is required.
> >>
> >> I'm seeing something similar happening in omp-low.c where the code in
> >> install_var_field and fixup_child_record_type both seem to rebuild the
> >> entire type from scratch if a field is either added or modified. Wouldn't
> >> it be possible simply modify the field(s) in question and rerun layout_type?
> >>
> >> I suspect the answer will be no but reasons as to why that wouldn't work
> >> will probably be equally valuable to me.
> > I think it's undesirable at least.  When last discussing "structure reorg"
> > I was always arguing that trying to change the "type" is the wrong angle
> > to look at (likewise computing something like "type escape").  It's
> > really individual objects you are transforming and that you need to track
> > so there may be very well instances of the original type T plus the
> > modified type T' in the program after the transform.
> >
> > Richard.
> >
> >> Thanks,
> >>
> >> Gary Oblock
> >>
> Richard,

Hope you don't mind I CC the list on my answer.

> You are right, in that T' is a whole new type that I'll be creating for
> the actual structure
> reorganization optimizations but if I have a pointer pointing to to a T'
> object I also have
> to change "that."

Well, actually you don't have to(*).  On GIMPLE what matters in the
end are the types of the actual memory accesses, the type of a record
field isn't important, esp. if it is "only" a pointer.

> Unfortunately, if this pointer  is an element of a
> structure type
> then I also have to modify that structure type. Note, there are
> situations where that pointer
> could possibly point to either T or T' in which case I have to
> disqualify the optimization
> on T. There are lot's details like that but this is probably not the
> best forum to transmit
> them.

I always thought people are too obsessed on "types" when doing
structure layout optimizations.  What they really are after is
optimizing memory layout and thus the transformation is on the
memory accesses.  IIRC the original implementation GCC had tried
to mostly get away with mangling the types and the actual memory
accesses changing "auto-magically".  But that severely limits
the application since once pointers are involved this "simple"
transform does not work.

So in my view memory layout optimization has to happen like

1) identify an interesting set of memory objects (a memory allocation
    point or a variable declaration)
2) make sure you can see _all_ accesses to that object (because you'll
    need to modify them)
3) cost/benefit/transform decision
4) rewrite the allocation/declaration and the accesses previously identified

see how types nowhere appear;  they might in deriving a transform in 3),
but that's for simplicity only.

> Back to my original question about modifying  the type, is rerunning
> layout_type reasonable?

If the layout changes then you'll have a problem unless you modify
all accesses anyways in which case you don't need that.

> I'm inspired by relayout_decl which clears a half a dozen or so fields
> and then calls layout_decl.
>
> I appreciate your answers and comments,

(*) There's the issue of debug information but IIRC that's unsolved for
this kind of transforms anyway.

> Gary