Re: Question about changing {machine,type} modes during LTO

[Erick Ochoa <erick.ochoa@theobroma-systems.com>]

Hi Richard,

Thanks! I can confirm that changing VAR_DECL's type
and calling relayout_decl fixes my problem.

On 2020-01-28 4:35 a.m., Richard Biener wrote:
> On Mon, Jan 27, 2020 at 6:41 PM Erick Ochoa
> <erick.ochoa@theobroma-systems.com> wrote:
>>
>> Hello,
>>
>> I have a problem with a transformation I'm working on and I would appreciate
>> some help. The transformation I am working on removes fields in structs early
>> during link-time. For the purposes of development and this example, my
>> transformation deletes the field identified as "delete_me" from the struct
>> identified as "astruct_s". These identifiers are hard coded in the
>> transformation at the moment.
>>
>> For example:
>>
>> ```c
>> int
>> main()
>> {
>>    struct astruct_s { _Bool a; _Bool delete_me; _Bool c;};
>>    // more
>> }
>> ```
>>
>> should be equivalent to
>>
>> ```c
>> int
>> main()
>> {
>>    struct astruct_s { _Bool a; _Bool c;};
>>    // more
>> }
>> ```
>>
>> as long as no instruction accesses field "delete me".
>>
>> I have succeeded in eliminating field "delete_me" from struct "astruct_s" and
>> at the same time successfully calculating field offsets and array offsets for
>> a subset of the C syntax. I am working on expanding the allowed syntax and at
>> the same time creating tests to verify my assumptions/work is still producing
>> correct results.
>>
>> I was starting work on supporting arrays of multiple dimensions, when I found
>> an interesting edge case in my transformation. I was able to transform structs
>> of size 2, 3, (but not 4), 5, 6, 7, (but not 8), 9, 10... This was the stack
>> trace when the error was triggered:
>>
>> ```
>> a.c: In function ‘main’:
>> a.c:11:19: internal compiler error: in convert_move, at expr.c:219
>>    11 |  struct astruct_s b = a[argc][argc];
>>       |                   ^
>> 0xb8bac3 convert_move(rtx_def*, rtx_def*, int)
>>         /home/eochoa/code/gcc/gcc/expr.c:219
>> 0xb9f5cf store_expr(tree_node*, rtx_def*, int, bool, bool)
>>         /home/eochoa/code/gcc/gcc/expr.c:5825
>> 0xb9d913 expand_assignment(tree_node*, tree_node*, bool)
>>         /home/eochoa/code/gcc/gcc/expr.c:5509
>> 0xa08bfb expand_gimple_stmt_1
>>         /home/eochoa/code/gcc/gcc/cfgexpand.c:3746
>> 0xa09047 expand_gimple_stmt
>>         /home/eochoa/code/gcc/gcc/cfgexpand.c:3844
>> 0xa1170f expand_gimple_basic_block
>>         /home/eochoa/code/gcc/gcc/cfgexpand.c:5884
>> 0xa134b7 execute
>>         /home/eochoa/code/gcc/gcc/cfgexpand.c:6539
>> Please submit a full bug report,
>> ```
>>
>> Looking at expr.c:219 I found the following assertions
>>
>> ```c
>> /* Copy data from FROM to TO, where the machine modes are not the same.
>>    Both modes may be integer, or both may be floating, or both may be
>>    fixed-point.
>>    UNSIGNEDP should be nonzero if FROM is an unsigned type.
>>    This causes zero-extension instead of sign-extension.  */
>>
>> void
>> convert_move (rtx to, rtx from, int unsignedp)
>> {
>>   machine_mode to_mode = GET_MODE (to);
>>   machine_mode from_mode = GET_MODE (from);
>>
>>   gcc_assert (to_mode != BLKmode);
>>   gcc_assert (from_mode != BLKmode); <-- crashes here
>> ```
>>
>> I started reading the gcc internals around machine modes:
>> https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html
>> and tried the experiment where I first compiled a struct of size 2 (and delete
>> field "delete_me"), then of size 3 and so on, and so on. I noticed that the
>> TYPE_MODE for matches the machine mode. And that it varies with the size of the
>> struct. (Which agrees with the definition of machine mode.)
>>
>> I originally thought that I needed to set TYPE_MODE myself, but if layout_type
>> is called after deleting the field (which it is), then TYPE_MODE is correctly
>> set somewhere within layout_type:
>> https://github.com/gcc-mirror/gcc/blob/68697710fdd35077e8617f493044b0ea717fc01a/gcc/stor-layout.c#L2203
>> I verified that layout_type is setting the correct values for TYPE_MODE when
>> transforming struct "astruct_s" by comparing the TYPE_MODE of different sizes
>> without the transformation applied. When transforming structs, layout_type
>> always returned a TYPE_MODE which matched the TYPE_MODE for unmodified structs
>> with the same size as the transformed struct (post transformation).
>>
>> In other words:
>>
>> For variable "struct not_transformed b" without transformation I obtain
>> the following relationship. Without transformation:
>>
>> | size | typemode |
>> |------|----------|
>> | 1    | 13       |
>> | 2    | 14       |
>> | 3    | 1        |
>> | 4    | 15       |
>> | 5    | 1        |
>> | 6    | 1        |
>> | 7    | 1        |
>> | 8    | 16       |
>> | 9    | 1        |
>>
>> With transformation (i.e. astruct_s b with a field named "delete_me")
>>
>> | size before | size after | typemode |
>> |-------------|------------|----------|
>> | 2           | 1          | 13       |
>> | 3           | 2          | 14       |
>> | 4           | 3          | 1        |
>> | 5           | 4          | 15       |
>> | 6           | 5          | 1        |
>> | 7           | 6          | 1        |
>> | 8           | 7          | 1        |
>> | 9           | 8          | 16       |
>>
>> I have a similar result for variable
>> "struct astructs b[]". Without modifications:
>>
>> | size | type_mode |
>> |------|-----------|
>> | 1    | 14       |
>> | 2    | 15       |
>> | 3    | 1        |
>> | 4    | 16       |
>> | 5    | 1        |
>> | 6    | 1        |
>>
>> With deletion of a field:
>>
>> | old size | size | type_mode|
>> |----------|------|----------|
>> | 2        | 1    | 14       |
>> | 3        | 2    | 15       |
>> | 4        | 3    | 1        |
>> | 5        | 4    | 16       |
>> |6         | 5    | 1        |
>> | 8        | 7    | 1        |
>> | 9        | 8    | 17       |
>> | 10       | 9    | 1        |
>>
>>
>>
>> So, going back to the error and the information that I had collected, I found
>> out that for structs of size 3 (and arrays holding structs of size 3) the
>> assigned TYPE_MODE for my machine should be BLKmode. E.g.
>>
>> ```c
>> int
>> main()
>> {
>>   struct untransformed { _Bool a; _Bool c; _Bool d;};
>>   struct untransformed b; // TYPE_MODE == BLKmode
>>   struct untransformed a[2]; // TYPE_MODE == BLKmode
>>   b = a[0];
>> }
>> ```
>>
>> So, when transforming structs of size 4, initially:
>>
>> ```c
>> int
>> main()
>> {
>>   struct astruct_s { _Bool a; _Bool c; _Bool delete_me; _Bool d;};
>>   struct astruct_s b; // TYPE_MODE != BLKmode
>>   struct astruct_s a[2]; // TYPE_MODE != BLKmode
>>   b = a[0];
>> }
>> ```
>>
>> However, after the struct is transformed, the TYPE_MODE becomes BLKmode.
>> This means, that the assertion that gets triggered is correct. `from_mode` is
>> indeed BLKmode and therefore the assertion gets triggered. "from_mode" should
>> be BLKmode, that's something I want and expect. And the assertion that is not triggered
>> `to_mode` is incorrect and should be triggered. This means to me that somehow we are
>> triggering a different execution path and hitting an assertion that we should
>> not have encountered in the first place.
>>
>> This leads me to believe that I have not changed a TYPE_MODE somewhere in the
>> gimple code. Maybe specifically the variable "b" (since this is where the "to"
>> of the expression `b = a[0]` should be. However, printing the gimple code after
>> the transformation, shows that b is the new variable type with the correct
>> TYPE_MODE:
>>
>> Before transformation
>> ```
>> Executing structreorg
>> main (int argc, char * * argv)
>> {
>>   struct astruct_s a[2];
>>   struct astruct_s b;
>>   int D.10221;
>>
>>   <bb 2> :
>>   b = a[0];
>>   b ={v} {CLOBBER};
>>   a ={v} {CLOBBER};
>>   _5 = 0;
>>
>>   <bb 3> :
>> <L0>:
>>   return _5;
>>
>> }
>> ```
>>
>> Some output of my pass:
>> ```
>> modifying,astruct_s
>> offset,astruct_reorged,a,0
>> offset,astruct_reorged,c,1
>> offset,astruct_reorged,d,2
>> old type_mode 15
>> new type_mode 1 // This is BLKmode
>> new type,astruct_reorged
>>
>> modifying,astruct_s[]
>> old type_mode 16
>> new type_mode 1 // This is BLKmode
>> new type,astruct_reorged[]
>> ```
>>
>> We can also look at the offending expression more indepth.
>> The type_mode's are unchanged here, but they are changed at the end.
>>
>> ```
>> b = a[0];
>> <rewrite_expr "b">
>> < type = astruct_s type_mode = 15>
>>     <rewrite_var_decl "b">
>>     < type = astruct_s type_mode = 15>
>>     </ type = astruct_s type_mode = 15>
>>     </rewrite_var_decl "b">
>> </ type = astruct_s type_mode = 15>
>> </rewrite_expr "b">
>>
>> <rewrite_expr "a[0]">
>> < type = astruct_s type_mode = 15>
>>     <rewrite_array_ref "a[0]">
>>     < type = astruct_s type_mode = 15>
>>
>>             <rewrite_expr "a">
>>             < type = astruct_s[] type_mode = 16>
>>                 <rewrite_var_decl "a">
>>                 < type = astruct_s[] type_mode = 16>
>>                 </ type = astruct_s[] type_mode = 16>
>>             </ type = astruct_s[] type_mode = 16>
>>             </rewrite_expr "a">
>>
>>             <rewrite_expr "0">
>>             < type = integer_cst type_mode = 15>
>>             </ type = integer_cst type_mode = 15>
>>             </rewrite_expr "0">
>>
>>     </ type = astruct_reorged type_mode = 1>
>>     </rewrite_array_ref "a[0]">
>>
>> </ type = astruct_reorged type_mode = 1>
>> </rewrite_expr "a[0]">
>>
>> // ...SNIP...
>>
>> <rewrite_expr "{CLOBBER}">
>> < type = astruct_s type_mode = 15>
>>     <rewrite_constructor "{CLOBBER}">
>>     < type = astruct_s type_mode = 15>
>>     </ type = astruct_reorged type_mode = 1>
>>     </rewrite_constructor "{CLOBBER}">
>> </ type = astruct_reorged type_mode = 1>
>> </rewrite_expr "{CLOBBER}">
>>
>> // ...SNIP...
>>
>> // Here is where the type mode are definitely modified for
>> // local variables
>> rewriting,local_decl  struct astruct_s a[2];,  struct astruct_reorged a[2];
>> rewriting,local_decl  struct astruct_s b;,  struct astruct_reorged b;
>>
>> ```
>>
>> After the pass finishes this is the gimple I see.
>>
>> ```
>>
>> main (int argc, char * * argv)
>> {
>>   struct astruct_reorged a[2];
>>   struct astruct_reorged b;
>>   int D.10221;
>>
>>   <bb 2> :
>>   b = a[0];
>>   b ={v} {CLOBBER};
>>   a ={v} {CLOBBER};
>>   _5 = 0;
>>
>>   <bb 3> :
>> <L0>:
>>   return _5;
>>
>> }
>> ```
>>
>> So just to summarize, things changed include:
>> * Variable's Type b
>> * Variable's Type a
>> * Expression's Type a[0]
>> * {CLOBBER} expression's type
>>
>> I have also tried using GDB to get a better grasp on how to fix the problem.
>> I use the following command to explore gcc's run time state in gdb.
>> $HOME/code/gcc-inst/bin/gcc -flto -fipa-typelist -fdump-ipa-typelist a.c -wrapper gdb,--args
>> I am able to see that the IPA passes are successfully executed, however, I am
>> never able to trigger a breakpoint during RTL generation. This is how I use gdb:
>>
>> * I go to the third gdb instance to look at the linker in gdb
>> * set catchpoints for fork and vfork
>> * and look at the inferior process #5 which is where LTO is applied.
>> * I've tried to set a breakpoint for symbols "execute" and I mostly just see
>> all IPA passes, but I do not see pass_expand::execute.
>> * I've also looked other inferior processes but I cannot set a
>> breakpoint before the assertion is hit. GCC just exists normally.
>>
>> Can anyone help me understand what could possibly be happening?
>> Some possibilities:
>> * Another LTO uses summary information and changes the type back to
>> non-BLKmode? (However, I also tried passing -flto-partition=none to
>> avoid summaries.)
>> * I am missing setting something in gimple which I do not know what that
>> could be? (Printing gimple doesn't show all information, but I did try
>> to set everything correctly).
>> * I am failing to communicate this change to other link time opts?
>> (I am changing the definition of this function as opposed to creating
>> a clone and then dropping the previous definition).
>> * Some other thing?
> 
> My first guess would be that you need to re-layout all decls that refer to the
> re-layouted type.
> 
> Richard.
> 
>> Any help would be appreciated!
>> Thanks
>>
>> -Erick