> ../../../.././gcc/libstdc++-v3/libsupc++/eh_personality.cc:805:1: internal > compiler error: in insert_insn_on_edge, at cfgrtl.cc:1976.
This error comes from assert of insert_insn_on_edge, the edge cannot be ABNORMAL and CRITIAL. Thus, I try to filter out it like gcse.cc:2168 do like below, but still hit some assert like regno < FIRST_PSEDUO_REGISTER in find_oldest_value_reg. If (eg->flags & EDGE_ABNORMAL) Insert_insn_end_basic_block else insert_insn_on_edge will continue to figure it out. Pan From: Li, Pan2 Sent: Thursday, July 27, 2023 9:38 AM To: 钟居哲 <[email protected]>; Jeff Law <[email protected]>; rdapp.gcc <[email protected]>; kito.cheng <[email protected]> Cc: gcc-patches <[email protected]>; Wang, Yanzhang <[email protected]> Subject: RE: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding Thanks Juzhe and Jeff for suggestion. The approach like emit_insn_before_noloc will result in below ICE here. ../../../.././gcc/libstdc++-v3/libsupc++/new_opant.cc:42:1: error: flow control insn inside a basic block. ../../../.././gcc/libstdc++-v3/libsupc++/new_opant.cc:42:1: internal compiler error: in rtl_verify_bb_insns, at cfgrtl.cc:2796 Then I tried below approach but also have ICE like below. ../../../.././gcc/libstdc++-v3/libsupc++/eh_personality.cc:805:1: internal compiler error: in insert_insn_on_edge, at cfgrtl.cc:1976. The insert_insn_end_basic_block have some special handling when end bb is CALL. Pan From: 钟居哲 <[email protected]<mailto:[email protected]>> Sent: Thursday, July 27, 2023 6:56 AM To: Jeff Law <[email protected]<mailto:[email protected]>>; rdapp.gcc <[email protected]<mailto:[email protected]>>; kito.cheng <[email protected]<mailto:[email protected]>>; Li, Pan2 <[email protected]<mailto:[email protected]>> Cc: gcc-patches <[email protected]<mailto:[email protected]>>; Wang, Yanzhang <[email protected]<mailto:[email protected]>> Subject: Re: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding Thanks Jeff. Hi, Pan: Plz try (insert edge and put 'frrm' on that edge) instead of insert end of block to see whether it works (I have tried onece but I don't remember what happens). Try that with following codes: edge eg; edge_iterator ei; FOR_EACH_EDGE (eg, ei, bb->succs) { start_sequence (); emit_insn (gen_frrmsi (DYNAMIC_FRM_RTL (cfun))); rtx_insn *backup_insn = get_insns (); end_sequence (); insert_insn_on_edge (backup_insn, eg); } to see how's going. Not sure whether it is correct, Jeff could comments on that. Thanks. ________________________________ [email protected]<mailto:[email protected]> From: Jeff Law<mailto:[email protected]> Date: 2023-07-27 06:46 To: 钟居哲<mailto:[email protected]>; rdapp.gcc<mailto:[email protected]>; kito.cheng<mailto:[email protected]>; pan2.li<mailto:[email protected]> CC: gcc-patches<mailto:[email protected]>; yanzhang.wang<mailto:[email protected]> Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding On 7/26/23 16:21, 钟居哲 wrote: > Hi, Jeff. > > insert_insn_end_basic_block is to handle this following case: > > bb 1: > ... > CALL.---->BB_END of bb > bb 2: > vfadd rne > > You can see there is no instructions after CALL. > > So you we use insert_insn_end_basic_block insert a "frrm" at the end of > the bb 1. > > I know typically it's better to insert a edge between bb 1 and bb 2, > then put "frrm" in that edgen. > However, it causes ICE. We'd need to know the reason for the ICE. > > If we really need to follow this approach, it seems that we need to > modify the "mode_sw" PASS? > Currently, we are avoiding changing the codes of PASS. Generally wise, but sometimes we do need to change generic bits. Let's dive a bit into this. We have more freedom here to loosen the profitability constraints since its a target specific pass, but let's at least understand the what's going on with the ICE, then make some decisions about the best way forward. jeff
