Re: A bug in vrp_meet?

[Jeff Law <law at redhat dot com>]

On 3/1/19 10:49 AM, Qing Zhao wrote:
> Jeff,
> 
> thanks a lot for the reply.
> 
> this is really helpful.
> 
> I double checked the dumped intermediate file for pass “dom3", and
> located the following for _152:
> 
> ****BEFORE the pass “dom3”, there is no _152, the corresponding Block
> looks like:
> 
>   <bb 4> [local count: 12992277]:
>   _98 = (int) ufcMSR_52(D);
>   k_105 = (sword) ufcMSR_52(D);
>   i_49 = _98 > 0 ? k_105 : 0;
> 
> ***During the pass “doms”,  _152 is generated as following:
> 
> Optimizing block #4
> ….
> Visiting statement:
> i_49 = _98 > 0 ? k_105 : 0;
> Meeting
>   [0, 65535]
> and
>   [0, 0]
> to
>   [0, 65535]
> Intersecting
>   [0, 65535]
> and
>   [0, 65535]
> to
>   [0, 65535]
> Optimizing statement i_49 = _98 > 0 ? k_105 : 0;
>   Replaced 'k_105' with variable '_98'
> gimple_simplified to _152 = MAX_EXPR <_98, 0>;
> i_49 = _152;
>   Folded to: i_49 = _152;
> LKUP STMT i_49 = _152
> ==== ASGN i_49 = _152
> 
> then bb 4 becomes:
> 
>   <bb 4> [local count: 12992277]:
>   _98 = (int) ufcMSR_52(D);
>   k_105 = _98;
>   _152 = MAX_EXPR <_98, 0>;
>   i_49 = _152;
> 
> and all the i_49 are replaced with _152. 
> 
> However, the value range info for _152 doesnot reflect the one for i_49,
> it keeps as UNDEFINED. 
> 
> is this the root problem?  
Yes, I think so.  It's like we didn't record anything for _152 when we
simplified the RHS to a MAX_EXPR.

Jeff