> On Jan 15, 2024, at 4:31 AM, Richard Biener <richard.guent...@gmail.com> > wrote: > > On Fri, Jan 12, 2024 at 6:30 PM Qing Zhao <qing.z...@oracle.com> wrote: >> >> Thanks a lot for the reply. >> >>> On Jan 12, 2024, at 11:28 AM, Richard Biener <richard.guent...@gmail.com> >>> wrote: >>> >>> >>> >>>> Am 12.01.2024 um 16:55 schrieb Qing Zhao <qing.z...@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. > > It's likely doing sth during gimplification.
So, before gimplification, when inserting tree node, we don’t need manually add unshare_expr since the gimplification will automatically unshare nodes. However, during or after gimplfication, when inserting nodes, we should manually add unshare_expr when we put the same “tree” into multiple operands. Is this understanding correct? >> So, usually, when should “unshare_expr” be used? > > You should usually unshare when you are putting the same 'tree' into multiple > operands. Okay, I see. > Using a SAVE_EXPR avoids redundant code but it also requires > that the SAVE_EXPR uses are ordered. “Require the SAVE_EXPR uses are ordered”, does this mean that SAVE_EXPRs for the same node should be in a correct order? Or something else? > >>>> 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? > > verify_node_sharing Okay, thanks. > >>> >>>> 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? > > Yes. > >> 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? > > This happens usually when you have a VLA type and its type fields are not > properly gimplified which usually happens because the frontend fails to > insert a gimplification point for it (a DECL_EXPR). Thanks for the info. This is happening for a structure TYPE with FAM (I guess similar as VLA?) Usually what’s the good solution to it? thanks. Qing > >> Thanks a lot for the help. >> >> Qing >> >> >>> >>> Richard >>> >>>> Thanks a lot for your help. >>>> >>>> Qing >>
