From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id 66B5C3858CDB for ; Thu, 20 Jul 2023 12:09:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66B5C3858CDB 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-x130.google.com with SMTP id 2adb3069b0e04-4fbb281eec6so1140964e87.1 for ; Thu, 20 Jul 2023 05:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689854987; x=1690459787; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/VPj2/MsGWbWb+32Hvf2rC8wU8cv9u/uuu7ExgIp1Ls=; b=fe2JQSDz21pM2PtqWCjYD2b5hyGSpualUc1DEMCn1adi4DRq23V6II9U8K+ZnDMO+E fOz+Y9aon0mzFhk5h9pNlvcrDojfLRadrvgZntpH0cKuaudAmZ+RLj2iuuooW6ozjHtf 6fwBnhvXSm1VJpUZI7O5UBH2SIhEw/VfN8R69Cp7/nkigN2Roh4nSR7J8B5ILi624PDo GqJxhGUfd0Kee/bdYVQBaASHxdgWgUBkHZgXYZEUnl59S6aw9waRetL70gFoENVOo1HQ o0lDTU+G3Wo8rfkc+A75wg31vhvKnRB9urOr/OVfwusibhCIB77vmeE3oOkyenBvHGKg OoQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689854987; x=1690459787; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/VPj2/MsGWbWb+32Hvf2rC8wU8cv9u/uuu7ExgIp1Ls=; b=ftbwz58gMM7UIe6bUUwReVYNdg1w14MIu3VQKfFEE25ErjYUPPfOW8bSC8/JsRsoIR mjD7CKmum36hVMG22QkEHDRdoX1BRxUYft99A9tG1xud78vOqaXbgUHxHv9bvi4GS7fl Kz4JWugM+LIlh5Zv4TzHDRHMr7TokCrvNM58LdhfnH1Mw5vEe5RjkbyDbXbheKiziBoa q0XYFoSE/gy9ULtb6e+5SYmyodteOq8HV/svuqkcs+wuvLh3o7aElNuOpUA/tMLuoFUx FxwIiV69m8thA3Os1yIVindaB6PW/yFUenU2BoRgjEIVja+aBfoUVHnVvxWhGRknlIKd 3GEg== X-Gm-Message-State: ABy/qLZ8a+k+0AE0jWlz58vwPqNEWQyWMrO7odIlZyemy4Hn/e/oBxgg kA8ouV4Gpr/1jx3vHgFqbnBxVvfGJtE0/AVKegM= X-Google-Smtp-Source: APBJJlFeZ5nppT475Kzo5azfPREnEvZE5IexXc7pUq/wdG4GNRqQ3jdnMS3wryPH8pnhOcjUOjOV5TgHugWRGOW9Mjc= X-Received: by 2002:a2e:a28c:0:b0:2b6:d89e:74e2 with SMTP id k12-20020a2ea28c000000b002b6d89e74e2mr2078225lja.7.1689854987116; Thu, 20 Jul 2023 05:09:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 20 Jul 2023 14:09:12 +0200 Message-ID: Subject: Re: [PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c To: "Maciej W. Rozycki" , Jiufu Guo Cc: YunQiang Su , Rainer Orth , Mike Stump , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Thu, Jul 20, 2023 at 11:16=E2=80=AFAM Maciej W. Rozycki wrote: > > On Thu, 20 Jul 2023, Richard Biener wrote: > > > > Thanks for making this improvement. I've checked MIPS results and c= ode > > > produced now is as follows: > > > > > > daddiu $sp,$sp,-64 > > > sd $5,24($sp) > > > sd $7,40($sp) > > > ldc1 $f0,24($sp) > > > ldc1 $f1,40($sp) > > > sd $4,16($sp) > > > sd $6,32($sp) > > > ldc1 $f2,32($sp) > > > add.ps $f1,$f0,$f1 > > > ldc1 $f0,16($sp) > > > add.ps $f0,$f0,$f2 > > > sdc1 $f1,56($sp) > > > ld $3,56($sp) > > > sdc1 $f0,48($sp) > > > ld $2,48($sp) > > > jr $31 > > > daddiu $sp,$sp,64 > > > > > > which does do vector stuff now, although it's still considerably wors= e > > > than my handwritten example: > > > > > > > > dmtc1 $4,$f0 > > > > > dmtc1 $5,$f1 > > > > > dmtc1 $6,$f2 > > > > > dmtc1 $7,$f3 > > > > > add.ps $f0,$f0,$f1 > > > > > add.ps $f2,$f2,$f3 > > > > > dmfc1 $2,$f0 > > > > > jr $31 > > > > > dmfc1 $3,$f2 > > > > > > Or I'd say it's pretty terrible, but given the current situation with= the > > > MIPS backend I'm going to leave it to the new maintainer to sort out. > > > > Yeah, I also wondered what is wrong ... I suspect it's the usual issue > > of parameter passing causing spilling ... > > There's no such requirement in the psABI and I fail to see a plausible > justification. And direct GPR<->FPR move patterns are available in the > backend for the V2SF mode. Also there's no delay slot requirement even > for these move instructions for MIPS64r1+ ISA levels, which have this > paired-single FP format defined. It seems to me a plain bug (or missed > optimisation if you prefer). Definitely. OTOH parameter/return passing for V4SFmode while appearantly being done in registers the backend(?) assigns BLKmode to the V4SFmode arguments so they get immediately spilled in the code moving the incoming hardregisters to pseudos (or stack as in this case). It comes down to the issue that Jiufu Guo is eventually addressing with adding SRA-style heuristics to the code chosing the layout of that storage. Interestingly for the return value we get TImode. Note we don't seem to be able to optimize (insn 6 21 8 2 (set (mem/c:DI (plus:DI (reg/f:DI 78 $frame) (const_int 24 [0x18])) [1 a+8 S8 A64]) (reg:DI 5 $5)) "t.c":4:1 322 {*movdi_64bit} (expr_list:REG_DEAD (reg:DI 5 $5) (nil))) ... (insn 40 7 41 2 (set (reg:V2SF 205 [ a+8 ]) (mem/c:V2SF (plus:DI (reg/f:DI 78 $frame) (const_int 24 [0x18])) [1 a+8 S8 A64])) "t.c":6:23 387 {*movv2sf} (expr_list:REG_EQUIV (mem/c:V2SF (plus:DI (reg/f:DI 78 $frame) (const_int 24 [0x18])) [1 a+8 S8 A64]) (nil))) for some reason. Maybe we are afraid of the hardreg use in the store, maybe it is because the store is in the prologue (before NOTE_INSN_FUNCTION_BEG). Also postreload isn't able to fix this: (insn 6 21 8 2 (set (mem/c:DI (plus:DI (reg/f:DI 29 $sp) (const_int 24 [0x18])) [1 a+8 S8 A64]) (reg:DI 5 $5)) "t.c":4:1 322 {*movdi_64bit} (nil)) ... (insn 40 7 41 2 (set (reg:V2SF 32 $f0 [orig:205 a+8 ] [205]) (mem/c:V2SF (plus:DI (reg/f:DI 29 $sp) (const_int 24 [0x18])) [1 a+8 S8 A64])) "t.c":6:23 387 {*movv2sf} (expr_list:REG_EQUIV (mem/c:V2SF (plus:DI (reg/f:DI 78 $frame) (const_int 24 [0x18])) [1 a+8 S8 A64]) (nil))) so something is amiss in the backend as well if you say there should be direct moves available. Richard. > > Maciej