From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id C2DF23858C2D for ; Thu, 2 Feb 2023 14:36:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C2DF23858C2D 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-pj1-x102b.google.com with SMTP id c10-20020a17090a1d0a00b0022e63a94799so5743159pjd.2 for ; Thu, 02 Feb 2023 06:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RNOxF3SUZ76rSRuZiyUa/0xBOEXjV9RLMyrqrmdjXqY=; b=ixUb4+Zoctp6779a6y/+WtpJHZRdwVLvO4XV5tZ1+ovlG0+kZp2EEbBU2vBuSXPfNb sUJkvvNLYDkaMVSk9aqfLJndYhmaGodJX1EoCWA2uw+kt8gmLQnH7wDP6TkX77lZ/nrU sGit/y8XOc6dtuaqo1y8MPuimdHx9MBTtV8lCnLC7h/1G/vh2EX/1YRewV1VnZUzjWaW NMzJthywwOCRXn3c+PyAT5xSmsqviiBcDbgQtN9Px7yHXl10a7106NKYONtQuhZM+OGt Q4Pz4QSp2Bb42FgIAZhgVBeToTo22ZFeIYtSmPTPyX7OT2u+MugRIHxxsxXHHpWYpTUn WItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RNOxF3SUZ76rSRuZiyUa/0xBOEXjV9RLMyrqrmdjXqY=; b=LIJeTQv9Qs2XuEkE0hIGNILxPFtgsPicR5ZXgTwWfalUiROoHWe/urQL32PGCzQS+D FHGwKCh36v6XygMMocgNCOWmzxqrqZ/pNGKssaXzuljfTZ5Ajxsqx5tgRFiftRRT0n7d e7MLh+jDdaRzI0GxHJiUhh0zqYhBpZqKrKE4NLxClUTYb584pZ9dw396LSO0trWyWU6L HAE9kIOSoGgGXCCmjagveIbUleVIBgwFiBqRxW17NZOqfB3/EmsShTq3926cbfAqM1hh asduGQ9JRTs4ee/hRYEkcT7HESBwRlyoh3ul2BsHoeBQs0gv+vMxiUqGkgzPQKax4C35 zKJQ== X-Gm-Message-State: AO0yUKWkZ6AvzJKei3R+NFHyAgUq2/Vhh+to5kNpfD8a/3b+xnlsWYQB d/C1yvnYNOfJTXWMZc00KgA= X-Google-Smtp-Source: AK7set8oWUoTDTvK/x1FRkQNp3eBdoCwqheky97eSiAY+VcXtMOGLXGM1lv993QiUA4U13900kBgCg== X-Received: by 2002:a17:90b:4a82:b0:22b:e4ad:d1e6 with SMTP id lp2-20020a17090b4a8200b0022be4add1e6mr6580954pjb.46.1675348591463; Thu, 02 Feb 2023 06:36:31 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 5-20020a17090a004500b00229b17bb1e8sm3261501pjb.34.2023.02.02.06.36.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Feb 2023 06:36:30 -0800 (PST) Message-ID: <678e451a-98da-2487-374d-72e9e15da36a@gmail.com> Date: Thu, 2 Feb 2023 07:36:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] CPROP: Allow cprop optimization when the function has a single block Content-Language: en-US To: Richard Biener , "juzhe.zhong@rivai.ai" Cc: gcc-patches , "kito.cheng" , "richard.sandiford" , apinski References: <2E16F446920AC99F+2023020120563582688674@rivai.ai> <0CEDD257-703F-4ED3-B927-C21279557CE6@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 2/2/23 05:26, Richard Biener wrote: > On Thu, 2 Feb 2023, juzhe.zhong@rivai.ai wrote: > >> Yeah, Thanks. You are right. CSE should do the job. >> Now I know the reason CSE failed to optimize is I include VL_REGNUM(66)/VTYPE_RENUM(67) hard reg >> as the dependency of pred_broadcast: >> (insn 19 18 20 4 (set (reg:VNx1DI 152) >>> (if_then_else:VNx1DI (unspec:VNx1BI [ >>> (const_vector:VNx1BI repeat [ >>> (const_int 1 [0x1]) >>> ]) >>> (const_int 4 [0x4]) >>> (const_int 2 [0x2]) repeated x2 >>> (const_int 0 [0]) >>> (reg:SI 66 vl) >>> (reg:SI 67 vtype) >>> ] UNSPEC_VPREDICATE) >>> (vec_duplicate:VNx1DI (reg/v:DI 148 [ x ])) >>> (unspec:VNx1DI [ >>> (const_int 0 [0]) >>> ] UNSPEC_VUNDEF))) "rvv.c":22:23 695 {pred_broadcastvnx1di} >>> (nil)) >> Then CSE failed to set the 152 as copy. >> >> VL_REGNUM(66)/VTYPE_RENUM(67) are the global hard reg that I should make each RVV instruction depend on them. >> Since we use vsetvl instruction (which is setting global VL_REGNUM(66)/VTYPE_RENUM(67) status) to set the global status for >> each RVV instruction. >> Including the dependency here is to make sure the global VL/VTYPE status is correct of each RVV instruction. (If we don't include >> such dependency in RVV instruction, instruction scheduling may move the RVV instructions and vsetvl instructions randomly then >> produce incorrect vsetvl configuration) >> >> The original reg_class of VL_REGNUM(66)/VTYPE_RENUM(67) I set here: >> riscv_regno_to_class [VL_REGNUM] = VL_REGS; >> riscv_regno_to_class [VTYPE_RENUM] = VTYPE_REGS; >> Such configuration make CSE failed. >> >> However, if I change the reg_class : >> riscv_regno_to_class [VL_REGNUM] = NO_REGS; >> riscv_regno_to_class [VTYPE_RENUM] = NO_REGS; >> The CSE now can do the optimization now! >> >> 1) Would you mind telling me the difference between them? > > No idea. I think CSE avoids to touch hard register references because > eliding them to copies can increase register pressure.IIRC the costing is set up differently and for a given partition a pseudo will be preferred over a hard reg. This is in addition to other places that test the small register class hooks. > >> 2) If I set these 2 global status register as NO_REGS, will it create >> issues for the global status configuration of each RVV instructions ? > > No idea either. Usually these kind of dependences are introduced > by targets at the point the VL setting is introduced to avoid > pessimizing optimizations earlier. Often, for cases like a VL > register, this is done after register allocation only and indeed > necessary to avoid the second scheduling pass from breaking things. Yea. I'm wondering about when the right place to introduce these dependencies might be. I'm still a few months out from worrying about RVV, but it's not too far away. jeff