Re: HELP: Questions on unshare_expr

[Qing Zhao <qing.zhao@oracle.com>]

Thanks a lot for the reply.  

> On Jan 12, 2024, at 11:28 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> 
> 
>> Am 12.01.2024 um 16:55 schrieb Qing Zhao <qing.zhao@oracle.com>:
>> 
>> Hi,
>> 
>> I have some questions on using the utility routine “unshare_expr”:
>> 
>> From my understanding, there should be NO shared nodes in a GENERIC function.
>> Otherwise, gimplication might fail.
> 
> There is sharing and this is why we unshare everything before gimplification.

Okay, so, the "unsharing everything” is done automatically by the compiler before gimplification? 
I don’t need to worry about this?

I see  many places in FE where “unshare_expr” is used, for example, “ubsan_instrument_division”,
 “ubsan_instrument_shift”, etc. 

So, usually, when should “unshare_expr” be used? 

>> Therefore, when we insert new tree nodes manually into the GENERIC function, we should
>> Make sure there is no shared nodes introduced.
>> 
>> 1. Is the above understanding correct?
> 
> No
> 
>> 2. Is there any tool to check there is no shared nodes in the GENERIC function?
>> 3. Are there any tree nodes that are allowed to be shared in a GENERIC function? If so, what are they?
> 
> There’s some allowed sharing on GIMPLE and a verifier.
What’s the name of the verifier that I can search and check? 
> 
>> 4. For the following:
>> 
>> If both “op1” and “op2” are existing tree nodes in the current GENERIC function,
>> and we will insert a new tree node:
>> 
>> tree  new_tree = build2 (CODE, TYPE, op1, op2)
>> 
>> 
>> Should we add “unshare_expr” on both “op1” and “op2” as:
>> 
>> Tree new_tree = build2 (CODE, TYPE, unshare_expr (op1), unshare_expr (op2))
>> ?
> 
> Not necessarily but instead you have to watch for evaluating side-effects only once.  See save_expr.

Okay.  I see.
> 
>> 
>> If op2 is a node that is allowed to be shared, whether the additional “unshare_expr” on it trigger any potential problem?
> 
> If you unshare side-effects that’s generating wrong-code.  Otherwise unsharing is safe.

Okay. 
Will unnecessary unshareing produce redundant IRs?

All my questions for unshare_expr relate to a  LTO bug that I currently stuck with 
when using .ACCESS_WITH_SIZE in bound sanitizer (only with -flto, without -flto, no issue):

[opc@qinzhao-aarch64-ol8 gcc]$ sh t
during IPA pass: modref
t.c:20:1: internal compiler error: tree code ‘ssa_name’ is not supported in LTO streams
0x14c3993 lto_write_tree
	../../latest-gcc-write/gcc/lto-streamer-out.cc:561
0x14c3aeb lto_output_tree_1

And the value of the tree node that triggered the ICE is:
(gdb) call debug_tree(expr)
 <ssa_name 0xfffff5761e60 type <error_mark 0xfffff56c0e58>
    nothrow
    def_stmt 
    version:13 in-free-list>

Is there any good way to debug LTO bug?

Thanks a lot for the help.

Qing


> 
> Richard 
> 
>> Thanks a lot for your help.
>> 
>> Qing