On Tue, 18 May 2021, Xionghu Luo wrote:

> Hi,
> 
> On 2021/5/18 15:02, Richard Biener wrote:
> > Can you, for the new gcc.dg/tree-ssa/ssa-sink-18.c testcase, add
> > a comment explaining what operations we expect to sink?  The testcase
> > is likely somewhat fragile in the exact number of sinkings
> > (can you check on some other target and maybe P8BE with -m32 for
> > example?), so for future adjustments it would be nice to easiliy
> > figure out what we expect to happen.
> > 
> > OK with that change.
> 
> Thanks a lot for the reminder! ssa-sink-18.c generates different code
> for m32 and m64 exactly due to different type size conversion and ivopts
> selection, since -m32 and -m64 couldn't co-exist in one test file, shall
> I restrict it to -m64 only or check target lp64/target ilp32?
> I've verified this case shows same behavior on X86, AArch64 and Power for
> both m32 and m64.
> 
> -m32:
>   <bb 29> [local count: 75120046]:
>   # len_155 = PHI <len_127(28), len_182(55)>
>   len_182 = len_155 + 1;
>   _35 = (unsigned int) ip_249;
>   _36 = _35 + len_182;
>   _380 = (uint8_t *) _36;
>   if (maxlen_179 > len_182)
>     goto <bb 30>; [94.50%]
>   else
>     goto <bb 31>; [5.50%]
> ...
> 
> Sinking _329 = (uint8_t *) _36;
>  from bb 29 to bb 86
> Sinking _36 = _35 + len_182;
>  from bb 29 to bb 86
> Sinking _35 = (unsigned int) ip_249;
>  from bb 29 to bb 86
> 
> Pass statistics of "sink": ----------------
> Sunk statements: 3
> 
> 
> -m64:
>   <bb 29> [local count: 75120046]:
>   # ivtmp.23_34 = PHI <ivtmp.23_36(28), ivtmp.23_35(55)>
>   _38 = (unsigned int) ivtmp.23_34;
>   len_161 = _38 + 4294967295;
>   _434 = (unsigned long) ip_254;
>   _433 = ivtmp.23_34 + _434;
>   _438 = (uint8_t *) _433;
>   if (_38 < maxlen_187)
>     goto <bb 30>; [94.50%]
>   else
>     goto <bb 31>; [5.50%]
> ...
> 
> Sinking _367 = (uint8_t *) _320;
>  from bb 31 to bb 90
> Sinking _320 = _321 + ivtmp.25_326;
>  from bb 31 to bb 90
> Sinking _321 = (unsigned long) ip_229;
>  from bb 31 to bb 90
> Sinking len_158 = _322 + 4294967295;
>  from bb 31 to bb 33
> 
> Pass statistics of "sink": ----------------
> Sunk statements: 4
> 
> 
> Regarding to the comments part:
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> index 52b9a74b65f..5147f7b85cd 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> @@ -193,16 +193,17 @@ compute_on_bytes (uint8_t *in_data, int in_len, uint8_t 
> *out_data, int out_len)
>    return op - out_data;
>   }
> + /* For this case, pass sink2 sinks statements from hot loop header to loop
> +    exits after gimple loop optimizations, which generates instructions 
> executed
> +    each iteration in loop, but the results are used outside of loop:
> +    With -m64,
> +    "Sinking _367 = (uint8_t *) _320;
> +     from bb 31 to bb 90
> +     Sinking _320 = _321 + ivtmp.25_326;
> +     from bb 31 to bb 90
> +     Sinking _321 = (unsigned long) ip_229;
> +     from bb 31 to bb 90
> +     Sinking len_158 = _322 + 4294967295;
> +    from bb 31 to bb 33"  */
> 
> - /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" } } */
> + /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { 
> target lp64 } } } */
> + /* { dg-final { scan-tree-dump-times "Sunk statements: 3" 1 "sink2" { 
> target ilp32 } } } */

Yes, that looks good.

Thanks,
Richard.

Reply via email to