From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 3F8A83857700 for ; Thu, 10 Aug 2023 13:23:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F8A83857700 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.01,162,1684828800"; d="scan'208";a="15798253" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 10 Aug 2023 05:23:48 -0800 IronPort-SDR: R4U+cC044qZrvxbk76KFNyPB2I0BHGOWvv92DzOwnIIY4sUtCqjjgUcXDURoDEXIh3Py2PwHjV 0pNgBhQDJhYUL5YAtrV9uDq31xb45Xgg64JVNuECGJU8IlhJfXXgcPzQsn/RMFqqJ56sWheC1Y NJ+9IUOEw9X2HgXkk0WAr1w25HBGEIz/F4e4hYkn+wth5eHojiIoj3CyLiRsJQb4H0PvmX+2LX uAPStEGk2gUHvE2TZPhQanHTPlkvUmqvh0tBVmcdxxvaq22MvdiwokDK8F5njMRsclz+bMbJK8 foM= From: Thomas Schwinge To: "Li, Pan2" , Richard Biener , Jakub Jelinek CC: , , , Jeff Law , , "Wang, Yanzhang" Subject: RE: Machine Mode ICE in RISC-V when LTO In-Reply-To: References: <87o7kxuq9s.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Thu, 10 Aug 2023 15:23:37 +0200 Message-ID: <878rajuj3a.fsf@dem-tschwing-1.ger.mentorg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On 2023-08-10T12:25:36+0000, "Li, Pan2" wrote: > Thanks Richard for comment, let me try to promote the table to unsigned s= hort. I have WIP work for this issue -- which I'd already raised a month ago: : On 2023-06-30T13:46:07+0200, Thomas Schwinge wrot= e: > In particular, the 'lto_mode_identity_table' changes would seem necessary > to keep standard LTO ('-flto') functional for large 'machine_mode' size? ... which is exactly the problem you've now run into? However, a simple: -GTY(()) const unsigned char *lto_mode_identity_table; +GTY(()) const unsigned short *lto_mode_identity_table; ..., or: -GTY(()) const unsigned char *lto_mode_identity_table; +GTY(()) const machine_mode *lto_mode_identity_table; ... is not sufficient: that runs into GTY issues, as the current 'unsigned char *lto_mode_identity_table' is (mis-)classified by 'gengtype' as a C string. This happens to work for this case, but still isn't right, and only works for 'char *' but not 'short *' etc. I have WIP work to tighten that. ..., which got me into other GTY issues, and so on... ;-) (Richard already ACKed and I pushed some of the prerequisite changes, but there's more to come.) I'm still planning on resolving all that mess, but I'm tight on time right now. However, I have a different proposal, which should address your current issue: simply, get rid of the 'lto_mode_identity_table', which is just that: a 1-to-1 mapping of array index to value. Instead, in 'gcc/lto/lto-common.cc:lto_file_finalize', for '!ACCEL_COMPILER', set 'file_data->mode_table =3D NULL', and in the users (only 'gcc/tree-streamer.h:bp_unpack_machine_mode'?), replace (untested): -return (machine_mode) ib->file_data->mode_table[ix]; +return ib->file_data->mode_table ? ib->file_data->mode_table[ix] : ix; Jakub, as the original author of 'lto_mode_identity_table' (see commit db847fa8f2cca6139188b8dfa0a7064319b19193 (Subversion r221005)), is there any reason not to do it this way? Gr=C3=BC=C3=9Fe Thomas > -----Original Message----- > From: Richard Biener > Sent: Thursday, August 10, 2023 7:08 PM > To: Li, Pan2 > Cc: richard.sandiford@arm.com; Thomas Schwinge ;= jakub@redhat.com; kito.cheng@gmail.com; Jeff Law ; = juzhe.zhong@rivai.ai; Wang, Yanzhang > Subject: Re: Machine Mode ICE in RISC-V when LTO > > On Thu, Aug 10, 2023 at 10:19=E2=80=AFAM Li, Pan2 wro= te: >> >> Hi all, >> >> >> >> Recently I found there is still some issues for the machine mode with LT= O part by fixing one >> >> ICE (only when compile with LTO) in RISC-V backend in , aka below case. >> >> >> >> >> ../__RISC-V_INSTALL___/bin/riscv64-unknown-elf-g++ -O2 -flto gcc/test= suite/g++.dg/torture/vshuf-v4df.C -o test.elf >> >> during RTL pass: expand >> >> gcc/testsuite/g++.dg/torture/vshuf-main.inc: In function 'main': >> >> gcc/testsuite/g++.dg/torture/vshuf-main.inc:15:9: internal compiler erro= r: in as_a, at machmode.h:381 >> >> 15 | V r =3D __builtin_shuffle(in1[i], mask1[i]); >> >> | ^ >> >> 0x7e5b8e scalar_int_mode as_a(machine_mode) >> >> ../.././gcc/gcc/machmode.h:381 >> >> 0x7eabdb scalar_mode as_a(machine_mode) >> >> ../.././gcc/gcc/expr.cc:332 >> >> 0x7eabdb convert_mode_scalar >> >> ../.././gcc/gcc/expr.cc:325 >> >> 0xb8485b store_expr(tree_node*, rtx_def*, int, bool, bool) >> >> ../.././gcc/gcc/expr.cc:6413 >> >> 0xb8a556 store_field >> >> ../.././gcc/gcc/expr.cc:7648 >> >> 0xb88f27 store_constructor(tree_node*, rtx_def*, int, poly_int<2u, long>= , bool) >> >> ../.././gcc/gcc/expr.cc:7588 >> >> 0xb8b8b8 expand_constructor >> >> ../.././gcc/gcc/expr.cc:8931 >> >> 0xb76bc7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_m= odifier, rtx_def**, bool) >> >> ../.././gcc/gcc/expr.cc:11170 >> >> 0xb77ef7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_m= odifier, rtx_def**, bool) >> >> ../.././gcc/gcc/expr.cc:10809 >> >> 0xb83a80 store_expr(tree_node*, rtx_def*, int, bool, bool) >> >> ../.././gcc/gcc/expr.cc:6325 >> >> 0xb851d9 expand_assignment(tree_node*, tree_node*, bool) >> >> ../.././gcc/gcc/expr.cc:6043 >> >> 0xa48717 expand_gimple_stmt_1 >> >> ../.././gcc/gcc/cfgexpand.cc:3946 >> >> 0xa48717 expand_gimple_stmt >> >> ../.././gcc/gcc/cfgexpand.cc:4044 >> >> 0xa4d030 expand_gimple_basic_block >> >> ../.././gcc/gcc/cfgexpand.cc:6096 >> >> 0xa4efd6 execute >> >> ../.././gcc/gcc/cfgexpand.cc:6831 >> >> >> >> I double checked the reason that comes from we add even more machine mod= es in the RISC-V backend, >> >> and then did some investigation for the root cause. It should be related= to the mode_table, as well as the >> >> bp_unpack_machine_mode. >> >> >> >> In lto_fe_init: >> >> unsigned char *table >> >> =3D ggc_vec_alloc (MAX_MACHINE_MODE); >> >> >> >> for (int m =3D 0; m < MAX_MACHINE_MODE; m++) >> >> table[m] =3D m; = <=3D=3D May overflow here given MAX_MACHINE_MODE > 256 and table[m] is= unsigned char. >> >> >> >> in bp_unpack_machine_mode: >> >> unsigned ix =3D bp_unpack_enum (bp, machine_mode, last); >> >> return (machine_mode) ib->file_data->mode_table[ix]; <=3D=3D May retu= rn truncated mode here. >> >> >> >> To validate this idea, I tried below hack code for double checking and t= hen there is no ICE anymore, which indicates >> >> the problem here as I bet. However, the lto is quite complicated and I a= m not sure how to fix it in the right way. >> >> >> >> + =3D ggc_vec_alloc (MAX_MACHINE_MODE * 2); >> >> =E2=80=A6 >> >> + ((unsigned short *)table)[m] =3D m; >> >> =E2=80=A6 >> >> + return (machine_mode) ((unsigned short *)ib->file_data->mode_table)[= ix]; >> >> >> >> Besides, I also tried to change the mode_table from char * to short * bu= t got one weird error when building as below. >> >> >> >> gcc/lto-streamer.h:599: field `(*x).mode_table' is pointer to unimplemen= ted type > > We still have some places using an array of char for the mode table. > The above is assigned > to lto_mode_identity_table which ends up in > lto_file_decl_data::mode_table. I think those > need to be all promoted to unsigned short. > > Richard. > >> >> >> Pan >> >> ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955