From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id C84C6385840D for ; Mon, 24 Apr 2023 08:08:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C84C6385840D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4ec816c9d03so4431025e87.2 for ; Mon, 24 Apr 2023 01:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682323732; x=1684915732; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BfkDqWa/Ku6u+DL3jJenVOQupfXmk+j8XNDt07TTWa0=; b=gowNJhxaFgyQKijU5v720bCHI5tW8Zs3egNbGaIN+wCaTQyBFtW3ki4PzISlFOU/Qi L+/lUl19CtFS/skf3TwNM1A8DL1sfmeCAPAzrliy4cVP7uIh2zdZCWjV+YIgoUC6B/cc Lr7A4wpwvSbjwdVzRhb0O0Fx6eKOD+97rZSgXKH4S/IaSqxy1tzBPGvOi7rseEq7A1zu O7Z464KfeehORZ4QAiGxmCB1wgW5of8dtUz0C1xi2Lk6KbvRu8vFRj3mNO1/GBg2QCIB pmENpGXKyBUOKrVWt1nz7NvkrHqKfILUgvDKdherC+u8t5umngXZ6R6Of8y48RPJnyaR cBTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682323732; x=1684915732; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BfkDqWa/Ku6u+DL3jJenVOQupfXmk+j8XNDt07TTWa0=; b=XW5QabytxoRTzkz99ZQN9VaciPtznnOlSBeum3+MdxSauMKyrHyQft0gCv4sHR1mP0 WYK8fgHoybfGOgEQv81QEX9kGNnsBzjhmg3Q2DyGJa80J5dlEZGaEQJcWN85NSNqGpEL SZNwnc+Q6nsEyS1NJ06rka4GJEi4wyCQy1eJJuS7OtG1XLVczv+IPsrz99CvKAmt9em1 T9alVJ4XX6zEfmIc68Fx1RglPXTjzog7NBg8SPh4A6vvXgBUNWeW1d+qBDFZCQ2jVvDO EHcb1OcLWkW7QIP5lBSDqtmfxFRMU/PutJox8b00XfCfyWGAC71xISzprbw9PVndQGfo j/4w== X-Gm-Message-State: AAQBX9dYcqzWmxamWJ3y0XPwGhFujKPqizbHfZo9VeFn+Khz39AztoX+ fA2BlZSYg/6KQ9V0RMys6Noy3H/4MGaJn1KqkOJimZi3k5U= X-Google-Smtp-Source: AKy350ZzEpY+QTwO2nEWvCIMp8LETQ4b3YnkSLUhmDKFYZzSIjA/Z60LsnQFOqlTtkRNBNFeeX6UBrzW0pKujKAja/E= X-Received: by 2002:ac2:5611:0:b0:4e8:3fc7:9483 with SMTP id v17-20020ac25611000000b004e83fc79483mr3211525lfd.23.1682323731919; Mon, 24 Apr 2023 01:08:51 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?6Iqx5LqV5b+X55Sf?= Date: Mon, 24 Apr 2023 17:08:40 +0900 Message-ID: Subject: Why spill_failure() aborts the compiler when hard-registers cannot find to spill pseudo-registers? To: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I am curious why spill_failure() in gcc/reload1.cc aborts the compiler. static void spill_failure (rtx_insn *insn, enum reg_class rclass) { if (asm_noperands (PATTERN (insn)) >=3D 0) error_for_asm (insn, "cannot find a register in class %qs while " "reloading %", reg_class_names[rclass]); else { error ("unable to find a register to spill in class %qs", reg_class_names[rclass]); if (dump_file) { fprintf (dump_file, "\nReloads for insn # %d\n", INSN_UID (insn)); debug_reload_to_stream (dump_file); } fatal_insn ("this is the insn:", insn); } } The above code aborts the compiler with the following error, for example (I am using m32c target because it has relatively few hardware registers to spill). m32c-elf-cc -B/root/r8c/newlib-4.1.0/m32c_build/m32c-elf/newlib/ -isystem /root/r8c/newlib-4.1.0/m32c_build/m32c-elf/new lib/targ-include -isystem /root/r8c/newlib-4.1.0/newlib/libc/include -B/root/r8c/newlib-4.1.0/m32c_build/m32c-elf/libglo ss/m32c -L/root/r8c/newlib-4.1.0/m32c_build/m32c-elf/libgloss/libnosys -L/root/r8c/newlib-4.1.0/libgloss/m32c -DPACKA GE_NAME=3D\"newlib\" -DPACKAGE_TARNAME=3D\"newlib\" -DPACKAGE_VERSION=3D\"4.1.0\" -DPACKAGE_STRING=3D\"newlib\ 4.1.0\" -DPACKAGE _BUGREPORT=3D\"\" -DPACKAGE_URL=3D\"\" -I. -I../../../../../newlib/libc/stdlib -Os -fno-builtin -DPREFER_SIZE_OVER_SPEED -DS MALL_MEMORY -DMISSING_SYSCALL_NAMES -DABORT_PROVIDED -DHAVE_INIT_FINI -g -O2 -c -o lib_a-ldtoa.o `test -f 'ldtoa.c' || echo '../../../../../newlib/libc/stdlib/'`ldtoa.c ../../../../../newlib/libc/stdlib/ldtoa.c: In function '_ldtoa_r': ../../../../../newlib/libc/stdlib/ldtoa.c:2936:1: error: unable to find a register to spill in class 'A_REGS' 2936 | } Regarding this documentation (Register allocation): https://gcc.gnu.org/onlinedocs/gccint/RTL-passes.html#RTL-passes > Reloading. This pass renumbers pseudo registers with the hardware > registers numbers they were allocated. Pseudo registers that did not > get hard registers are replaced with stack slots. So if the optimizer cannot find hard-registers to spill pseudo-registers, it is not a serious situation and happily allocate memory slots in the stack area instead. I tried the following change against GCC 12 and confirmed the above error has gone. else { - error ("unable to find a register to spill in class %qs", - reg_class_names[rclass]); - if (dump_file) { fprintf (dump_file, "\\nReloads for insn # %d\\n", INSN_UID (insn)); debug_reload_to_stream (dump_file); } - fatal_insn ("this is the insn:", insn); } --=20 =E8=8A=B1=E4=BA=95 =E5=BF=97=E7=94=9F Ruimo Uno (Shisei Hanai)