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 F39013858D28 for ; Fri, 31 Mar 2023 14:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F39013858D28 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 lr16-20020a17090b4b9000b0023f187954acso23538126pjb.2 for ; Fri, 31 Mar 2023 07:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680273357; x=1682865357; 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=unLr2lGyIVgJA0vxZ2TztfEO5+EH+qjgO44Yf0O/0ts=; b=IAFEKJr+Ck5y9a83lDukL0OWMnntD/HPEh1I6le7zvOPD7jCHSujsDeQ1LBWHDsGFi fmTy3dzqiteIxiddPukyaxIeJdFLz7AdvJ4oUl9G13P+mOTGWQS29ST5kUOble9o6G0H QnDyTg7CtYn1TTPrGuUwbshHhormlxKr8FsKbegC3KiqjJkkENf98Jx6JfDZON/EsYtX DEy5a0N6DVwXhp0oUxHsgjHSRliAEro6yRrQqbcm4Po9jHV0mjDXOe5VkVg6zCmwXS9L FUG6HCE6jyHPrE+U4WZV6jUPQWej3GOYwu3rmB/9s1zgkqzpmh1E64svDj+whWP/lbqm mYXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680273357; x=1682865357; 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=unLr2lGyIVgJA0vxZ2TztfEO5+EH+qjgO44Yf0O/0ts=; b=kybCl4AnKIy37Iti6+JTdjgkryd2B5NgLvToZcEdM7DBrl8Nfj+brkUYrmN8OL+YQ5 8+XyEA1fyKbOt7Fgb4Vr4eZbRBput2GlLSgIj076rpzWXcdD0lD+CdrCo9VEitKcBV5K a5HUQ48ZWMWX3Lz7TBV01Tw1+qytZaDkV728BP8EAKXS8QxlaxWLmleMe4vvu/EAWLhR Z4+BNmeA+9fc5WQWP1Nv3DjnJtFyJtE6058hz36BaaS58R3UU0x9MKblPLbsJDYzb9eJ f7dCfBs0tPt4i5JyL3s3iMmMz7aES2YnqQxLq1RMnuWqqMF4oDJJGwSewD1EUncQkVyK tXvw== X-Gm-Message-State: AAQBX9fOQx1nWYYXXxjj2H1UkdsyEUZd7C5hS0DSCl2HjfBmOGYhjY11 exOgpXmMOR4qNf3jk2ID71Q= X-Google-Smtp-Source: AKy350a8LPhbsjvG+evV2QqDvRQXJ0NJCLQA5gWxwx74YFD7fuSfY4t9rKwWk/BcfhxMQTo19ynbjQ== X-Received: by 2002:a17:903:283:b0:1a1:b748:f360 with SMTP id j3-20020a170903028300b001a1b748f360mr33539514plr.47.1680273356747; Fri, 31 Mar 2023 07:35:56 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id v6-20020a170902b7c600b001967580f60fsm1617812plz.260.2023.03.31.07.35.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 07:35:56 -0700 (PDT) Message-ID: Date: Fri, 31 Mar 2023 08:35:55 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc. [PR109254] Content-Language: en-US To: Jakub Jelinek , Richard Sandiford , Richard Earnshaw Cc: gcc-patches@gcc.gnu.org References: 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.3 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 3/24/23 15:59, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The testcase in the PR (which unfortunately because of my lack of experience > with SVE I'm not able to turn into a runtime testcase that verifies it) > is miscompiled on aarch64-linux in the regname pass, because while the > function takes arguments in the p0 register, FUNCTION_ARG_REGNO_P doesn't > reflect that, so DF doesn't know the register is used in register passing. > It sees 2 chains with p1 register and wants to replace the second one and > as DF doesn't know p0 is live at the start of the function, it will happily > use p0 register even when it is used in subsequent instructions. > > The following patch fixes that. FUNCTION_ARG_REGNO_P returns non-zero > for p0-p3 (unconditionally, seems for the floating/vector registers it > doesn't conditionalize them on TARGET_FLOAT either, but if you want, > I can conditionalize p0-p3 on TARGET_SVE), similarly > targetm.calls.function_value_regno_p returns true for p0 register > if TARGET_SVE (again for consistency, that function conditionalizes > the float/vector on TARGET_FLOAT); looking at the AAPCS, seems p1-p3 > could be also used to return values in case of homogenous aggregates, > but it doesn't seem GCC supports putting svbool_t as a member of a > structure. > > Now, that change broke bootstrap in libobjc and some > __builtin_apply_args/__builtin_apply/__builtin_return tests. The > aarch64_get_reg_raw_mode hook already documents that SVE scalable arg/return > passing is fundamentally incompatible with those builtins, but unlike > the floating/vector regs where it forces a fixed vector mode, I think > there is no fixed mode which could be used for p0-p3. So, I have tweaked > the generic code so that it uses VOIDmode return from that hook to signal > that a register shouldn't be touched by > __builtin_apply_args/__builtin_apply/__builtin_return > despite being mentioned in FUNCTION_ARG_REGNO_P or > targetm.calls.function_value_regno_p. > > Bootstrapped/regtested on aarch64-linux, ok for trunk? > > Could somebody please turn the testcase from the PR into something that > can be included into the testsuite? > > 2023-03-24 Jakub Jelinek > > PR target/109254 > * builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode > returns VOIDmode, handle it like if the register isn't used for > passing arguments at all. > (apply_result_size): If targetm.calls.get_raw_result_mode returns > VOIDmode, handle it like if the register isn't used for returning > results at all. > * target.def (get_raw_result_mode, get_raw_arg_mode): Document what it > means to return VOIDmode. > * doc/tm.texi: Regenerated. > * config/aarch64/aarch64.cc (aarch64_function_value_regno_p): Return > TARGET_SVE for P0_REGNUM. > (aarch64_function_arg_regno_p): Also return true for p0-p3. > (aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs. Generic bits are OK by me. The aarch64 bits looks sensible, but I'd like to give the aarch folks one more chance to chime in. So OK for the trunk Monday if you haven't heard otherwise. jeff