Re: [EXT] Re: Modifying types during optimization
On Wed, Oct 2, 2019 at 8:50 PM Gary Oblock wrote: > > On 10/2/19 3:15 AM, Richard Biener wrote: > > External Email > > > > -- > > On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock 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
Re: [EXT] Re: Modifying types during optimization
On 10/2/19 3:15 AM, Richard Biener wrote: > External Email > > -- > On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock 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: Modifying types during optimization
On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock 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 >
Modifying types during optimization
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
