Re: [EXT] Re: Modifying types during optimization

[Gary Oblock <goblock at marvell dot com>]

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