From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id C3B1A3858D33 for ; Mon, 25 Mar 2024 22:31:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C3B1A3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C3B1A3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711405876; cv=none; b=MoW5nkjNp4Vi3Zw9XtOBfCCWtpqyGwrZjdJYEoHluzrtn8W9Y1V9dt8LLtdbzpBtholAEKEmnMe3SSayk6il+MUzTNLfLp3AhZrbyaGyd4PWtPXXMcaGG469x/fyX5nD0JozHbnXwEevtAXoHB4SP2AF47ZUhVLOiQXtRRIK70A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711405876; c=relaxed/simple; bh=ym0nOrRAZ1n/xTrdIf7xgtO8xu5muDLdQC7jyGmHAhk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vif3U+7dJaK/rts9X2IkSPBI4lK0xTb7kt9W2Eix/rM3PcdJFgdBwsGIMAW6kzGqGiF/jd/FWYJnEXQoT3mmV5Ns/lPL6zizZ/DnZtYF2MXX7Z7J1BxkZxAT2a6b8THkSnZjyDfIVHDvtud/G4/iMf1lGxpc1Aj5Cg7oD998w3A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-29df3333d30so3415240a91.1 for ; Mon, 25 Mar 2024 15:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711405874; x=1712010674; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=J0EvnHgSqXoQLVo957f5kTeHvwIwBZHR5695diXGjwc=; b=nD8Hmd6N157cfRaJmGT3AJmtNOpeJ/JxQOdN5jrbUjL76VUrreCuScy7rCNheZGxMj 9bKqRjtqQVIziich8/hrgKrn6lXNd8Q1hiWD7FBLbNottwvnQHRom19WnAWKsNqCzGqp lOvKy38EBNYDyIOeNNYTbA7029lqoovVYQ8aRXv0rrka0bMaknEB/p+k8Nntc1gwHRi8 f0edWSSCZ5Gl0Pf00uM8MmYsOU7Es8c+dwoMHHUdwfswKt3ivk6lrqvS1yw7xtUAQBHL 0fizXG1stVb6GkDkeQeM8PxrYsfDidMvIy8P/bgePSRldy9hpfB4tO8TCCNxDyL3I2KO czqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711405874; x=1712010674; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=J0EvnHgSqXoQLVo957f5kTeHvwIwBZHR5695diXGjwc=; b=O12kwoRApCJKExhmuetPyB2njOqX+Hi4L732YEUoN0SFMIIGNVl6IS1S/5fFNKXa6Q IlSniEck8+KtlefPQBC8jOpXy9SHSzwSkWQNOwTu3QCSo6trRNdGkm06bahv9LQ+oM3l EC5YTJYQDSeDnZ7jIgH4u4N8XLRVXs5/Mf7SItOTlotZgpEBYqiJBbrnWpxbBcfq43hX qbgkUkHp7cExPJjk3VtOrbbVNhwFrLLPxyHFyAE9w+QDgj7+R2pbxphYpJdX2yJKWc4I vbpE81wgHzXTaztypsMyCbby7YXonFpiSdTAcc5iVMfufmZvCTxQfrUVwarNECveeWPR 1HEw== X-Gm-Message-State: AOJu0YyIFhX6wL73ovDUWWJxTr3p+sKHXBFDhb1yhBtZ2+3BOjMQQ9vV F2TsWfWaSQHqVz4o2gEPLlZq6DOeYkT0u+F8bIWr7/M37krLm95F1x7AsDvQkBVAa4aZlETVgv3 MmOER1ed63mIwxqJI8aDP5Jnau0gl18hW X-Google-Smtp-Source: AGHT+IEq1fCpqTyDiiNR/dlFVpSSZrU+LpzZaQBOPDz+Kn+if75l5Ou7VQkOWcEL1ul/8jbyG3n0QraKFVIGYkTYZ8Q= X-Received: by 2002:a17:90a:d703:b0:2a0:2f77:842a with SMTP id y3-20020a17090ad70300b002a02f77842amr6226914pju.42.1711405873657; Mon, 25 Mar 2024 15:31:13 -0700 (PDT) MIME-Version: 1.0 From: Max Filippov Date: Mon, 25 Mar 2024 15:31:02 -0700 Message-ID: Subject: unneeded spills of SF values on xtensa with FPU To: "Takayuki 'January June' Suwa" Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Suwa-san, I've noticed that in xtensa configurations with hardware FPU function arguments of type float are spilled on the stack although there's no need for that. E.g. the following function: int f(float a, float b) { return a < b; } translates to the following with -O2: f: entry sp, 48 wfr f0, a2 wfr f1, a3 s32i.n a2, sp, 0 olt.s b0, f0, f1 movi.n a8, 0 movi.n a2, 1 s32i.n a3, sp, 4 movf a2, a8, b0 retw.n The relevant RTL looks like this at the end of IRA: (insn 18 4 19 2 (set (reg:SF 51) (reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal} (expr_list:REG_DEAD (reg:SF 2 a2 [ a ]) (nil))) (insn 19 18 7 2 (set (reg:SF 52) (reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal} (expr_list:REG_DEAD (reg:SF 3 a3 [ b ]) (nil))) (insn 7 19 21 2 (set (reg:CC 18 b0) (lt:CC (reg:SF 51) (reg:SF 52))) "test2.c":3:11 100 {slt_sf} (expr_list:REG_DEAD (reg:SF 52) (expr_list:REG_DEAD (reg:SF 51) (nil)))) and it is transformed to the following by the end of LRA: (insn 18 4 19 2 (set (mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32]) (reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal} (nil)) (insn 19 18 24 2 (set (mem/c:SF (plus:SI (reg/f:SI 1 sp) (const_int 4 [0x4])) [1 %sfp+4 S4 A32]) (reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal} (nil)) (insn 24 19 25 2 (set (reg:SF 19 f0 [51]) (mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32])) "test2.c":3:11 61 {movsf_internal} (nil)) (insn 25 24 7 2 (set (reg:SF 20 f1 [52]) (mem/c:SF (plus:SI (reg/f:SI 1 sp) (const_int 4 [0x4])) [1 %sfp+4 S4 A32])) "test2.c":3:11 61 {movsf_internal} (nil)) (insn 7 25 21 2 (set (reg:CC 18 b0) (lt:CC (reg:SF 19 f0 [51]) (reg:SF 20 f1 [52]))) "test2.c":3:11 100 {slt_sf} (nil)) LRA stops checking alternatives for insns 18 and 19 at s32i.n, but even if I move wfr at the head of the movsf_internal list it still loses to s32i.n. Postreload pass replaces the lsi instructions 24 and 25 with wfr from a2 and a3, but doesn't remove the spills. I wonder what can be done with that? -- Thanks. -- Max