> On Feb 2, 2021, at 1:43 AM, Richard Biener <rguent...@suse.de> wrote:
>
> On Mon, 1 Feb 2021, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion.
>>
>> And now the routine “bump_map” in 511.povray is like following:
>> ...
>>
>> # DEBUG BEGIN_STMT
>> xcoor = 0.0;
>> ycoor = 0.0;
>> # DEBUG BEGIN_STMT
>> index = .DEFERRED_INIT (index, 2);
>> index2 = .DEFERRED_INIT (index2, 2);
>> index3 = .DEFERRED_INIT (index3, 2);
>> # DEBUG BEGIN_STMT
>> colour1 = .DEFERRED_INIT (colour1, 2);
>> colour2 = .DEFERRED_INIT (colour2, 2);
>> colour3 = .DEFERRED_INIT (colour3, 2);
>> # DEBUG BEGIN_STMT
>> p1$0_181 = .DEFERRED_INIT (p1$0_195(D), 2);
>> # DEBUG p1$0 => p1$0_181
>> p1$1_184 = .DEFERRED_INIT (p1$1_182(D), 2);
>> # DEBUG p1$1 => p1$1_184
>> p1$2_172 = .DEFERRED_INIT (p1$2_185(D), 2);
>> # DEBUG p1$2 => p1$2_172
>> p2$0_177 = .DEFERRED_INIT (p2$0_173(D), 2);
>> # DEBUG p2$0 => p2$0_177
>> p2$1_135 = .DEFERRED_INIT (p2$1_178(D), 2);
>> # DEBUG p2$1 => p2$1_135
>> p2$2_137 = .DEFERRED_INIT (p2$2_136(D), 2);
>> # DEBUG p2$2 => p2$2_137
>> p3$0_377 = .DEFERRED_INIT (p3$0_376(D), 2);
>> # DEBUG p3$0 => p3$0_377
>> p3$1_379 = .DEFERRED_INIT (p3$1_378(D), 2);
>> # DEBUG p3$1 => p3$1_379
>> p3$2_381 = .DEFERRED_INIT (p3$2_380(D), 2);
>> # DEBUG p3$2 => p3$2_381
>>
>>
>> In the above, p1, p2, and p3 are all splitted to calls to DEFERRED_INIT of
>> the components of p1, p2 and p3.
>>
>> With this change, the stack usage numbers with -fstack-usage for approach A,
>> old approach D and new D with the splitting in SRA are:
>>
>> Approach A Approach D-old Approach D-new
>>
>> 272 624 368
>>
>> From the above, we can see that splitting the call to DEFERRED_INIT in SRA
>> can reduce the stack usage increase dramatically.
>>
>> However, looks like that the stack size for D is still bigger than A.
>>
>> I checked the IR again, and found that the alias analysis might be
>> responsible for this (by compare the image.cpp.026t.ealias for both A and D):
>>
>> (Due to the call to:
>>
>> colour1 = .DEFERRED_INIT (colour1, 2);
>> )
>>
>> ******Approach A:
>>
>> Points_to analysis:
>>
>> Constraints:
>> …
>> colour1 = &NULL
>> …
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> ...
>> callarg(53) = &colour1
>> ...
>> _53 = colour1
>>
>> Points_to sets:
>> …
>> colour1 = { NULL ESCAPED NONLOCAL } same as _53
>> ...
>> CALLUSED(48) = { NULL ESCAPED NONLOCAL index colour1 }
>> CALLCLOBBERED(49) = { NULL ESCAPED NONLOCAL index colour1 } same as
>> CALLUSED(48)
>> ...
>> callarg(53) = { NULL ESCAPED NONLOCAL colour1 }
>>
>> ******Apprach D:
>>
>> Points_to analysis:
>>
>> Constraints:
>> …
>> callarg(19) = colour1
>> callarg(19) = &NONLOCAL
>> colour1 = callarg(19) + UNKNOWN
>> colour1 = &NONLOCAL
>> …
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> colour1 = &NONLOCAL
>> …
>> callarg(74) = &colour1
>> callarg(74) = callarg(74) + UNKNOWN
>> callarg(74) = *callarg(74) + UNKNOWN
>> …
>> _53 = colour1
>> _54 = _53
>> _55 = _54 + UNKNOWN
>> _55 = &NONLOCAL
>> _56 = colour1
>> _57 = _56
>> _58 = _57 + UNKNOWN
>> _58 = &NONLOCAL
>> _59 = _55 + UNKNOWN
>> _59 = _58 + UNKNOWN
>> _60 = colour1
>> _61 = _60
>> _62 = _61 + UNKNOWN
>> _62 = &NONLOCAL
>> _63 = _59 + UNKNOWN
>> _63 = _62 + UNKNOWN
>> _64 = _63 + UNKNOWN
>> ..
>> Points_to set:
>> …
>> colour1 = { ESCAPED NONLOCAL } same as callarg(19)
>> …
>> CALLUSED(69) = { ESCAPED NONLOCAL index colour1 }
>> CALLCLOBBERED(70) = { ESCAPED NONLOCAL index colour1 } same as CALLUSED(69)
>> callarg(71) = { ESCAPED NONLOCAL }
>> callarg(72) = { ESCAPED NONLOCAL }
>> callarg(73) = { ESCAPED NONLOCAL }
>> callarg(74) = { ESCAPED NONLOCAL colour1 }
>>
>> My question:
>>
>> Is it possible to adjust alias analysis to resolve this issue?
>
> You probably want to handle .DEFERRED_INIT in tree-ssa-structalias.c
> find_func_aliases_for_call (it's not a builtin but you can look in
> the respective subroutine for examples). Specifically you want to
> avoid making anything escaped or clobbered.
Okay, thanks.
Will check on that.
Qing
>>
>
> --
> Richard Biener <rguent...@suse.de <mailto:rguent...@suse.de>>
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
