From patchwork Wed Aug 30 12:22:13 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robin Dapp X-Patchwork-Id: 137173 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a7d1:0:b0:3f2:4152:657d with SMTP id p17csp4499965vqm; Wed, 30 Aug 2023 05:23:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG5lSAspnrQQG1PFsE/kVSxUpHIoCL1ujNsqbX/pUJGZNNVAEA6CbYtEWQ6y4+rW/0vaM5O X-Received: by 2002:a17:906:3058:b0:9a1:bee8:9252 with SMTP id d24-20020a170906305800b009a1bee89252mr1837769ejd.29.1693398180934; Wed, 30 Aug 2023 05:23:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693398180; cv=none; d=google.com; s=arc-20160816; b=zedvv33M7OGfdIgiOpNeqgQ50ObN/A9agfuCkeSIkx/f4MxtuGcWppOdaW8A6PaXxC lILO3aUlnFI6OGBRRZAkNXCQCX0F7ZGFK7QRzPC6eZa+5qVhSkNjbuQSF1zdHtO6CO1p fVasVGUe7pO3hfrxxj3rDZamAshtcnr99h2mMpzMbOMHqX0N8mqTTEElGLoGGtTb41ht L24QJxVjjQe+L6yTyzefb3XtjjpGvfNgGoefW5C1iNAgxFtnjQBtzNin/slNakglI4DQ EvqW+tb/u+iadpkC6v46oihij9Xhef3kTphbfzxRmCzJlMYGjMktmzY1drIqw2SIZkto JYMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:subject:to:content-language:user-agent :mime-version:date:message-id:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=A5iq3/Yzr8eDF3vbzeWOdmLeSZmFfewO/bB6kz/HmmI=; fh=KUU620Cn5xvkLvKM+xwrOU5CyEzThH83d2flIfyBqxg=; b=Zw5aDIrgw4L76QJIX1kLPRnHJcqIujJBFXUnep75y9MUgs3RiF62o7++XYv0VhZKh+ FNsAYrqBvE56JM2pfzoZ1wVTYYciJmcLh7wN6Zvs7JCxUSVHuEnoWryNz8ZvRbYyHFlK 3GH9cMGe1LLEqH7D9VJYPBIlTf0WwhSzYbMobWEImXwMz4fDvvX6iA6Z5FDbOFqdsQlh LJdFdQV+bWnWfIE9XuVvCHFI6ZEyqp4ihtOovIo2bc76eI90x/RqSq9t0B+FkbjZfkFw rGfWgCZecvb5iEFEMG6OutQkXpPvUigk0PLPsXtmZMYMKgsb+fCHvCK2horkkNCsKLLl uiEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=YuGgSLIO; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id z15-20020a170906074f00b00997d4f19a04si5321710ejb.723.2023.08.30.05.23.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Aug 2023 05:23:00 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=YuGgSLIO; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 66D673858284 for ; Wed, 30 Aug 2023 12:22:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66D673858284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1693398179; bh=A5iq3/Yzr8eDF3vbzeWOdmLeSZmFfewO/bB6kz/HmmI=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=YuGgSLIOLDsI9fz3zpuXVE4//pvT4l9PYEI8AuZbp/NlEuGmLKpQ3QSYCO8Dl8mDk UNJUB8jvSQDJUYLiM5P6Vzbw0tuUwp93XuG0it0OWozx7vKAd1TD1TVTOn/aEFta+v YihdCNmHceOWyT1PZvFfr9qUXt42QsJNjSr2toyU= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 3B1253858D28 for ; Wed, 30 Aug 2023 12:22:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3B1253858D28 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-52a4818db4aso7012739a12.2 for ; Wed, 30 Aug 2023 05:22:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693398134; x=1694002934; h=content-transfer-encoding:subject:from:to:content-language:cc :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=A5iq3/Yzr8eDF3vbzeWOdmLeSZmFfewO/bB6kz/HmmI=; b=Nv7fEvDAF3a3hKAao1Nwa9BuNFfwK5gzvvgMtiKKdo4zEgAK6nzsYnT6cCVaRi0prE jidt7CMMyIeNJnlFrW/AGp9aTGyWgi9K7KkkcYl0+m6Rk93en2tmlp0KDyj1cX/dNVPT NxbQZR3+RQB/+a+wIRpO0X8r3aLoJ1vIIFQ5+M8ENsM8EJkyDEKFXoytUj0OZA0JpBcm LiIJX2oWmEfjuQtiKGv/C7rUscA4LIRu6kA0hWHnbSGjXVM7gwC8HAcYjsAICknOjdDN A7rV5hRuBPVEumxpvrZZiCDpqd0f+MaOUkXqxRpBytVoTYGSHnFEtbHwOOo7dkXlrMWw 1E4g== X-Gm-Message-State: AOJu0YydXJkbJ68j0HZ6fQhp2cP0lxt5jVm6keseF/vdewBti7JejJSp R8l3d0u+OV7mzXtbaP1txlIdAhJp8q4= X-Received: by 2002:aa7:c3c3:0:b0:525:6e47:10f6 with SMTP id l3-20020aa7c3c3000000b005256e4710f6mr1782412edr.22.1693398134130; Wed, 30 Aug 2023 05:22:14 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id w22-20020a50fa96000000b0052a3aa50d72sm6704987edr.40.2023.08.30.05.22.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Aug 2023 05:22:13 -0700 (PDT) Message-ID: Date: Wed, 30 Aug 2023 14:22:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: gcc-patches , "richard.sandiford" Subject: [PATCH] expmed: Allow extract_bit_field via mem for low-precision modes. X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Robin Dapp via Gcc-patches From: Robin Dapp Reply-To: Robin Dapp Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1775656691257559337 X-GMAIL-MSGID: 1775656691257559337 Hi, when looking at a riscv ICE in vect-live-6.c I noticed that we assume that the variable part (coeffs[1] * x1) of the to-be-extracted bit number in extract_bit_field_1 is a multiple of BITS_PER_UNIT. This means that bits_to_bytes_round_down and num_trailing_bits cannot handle e.g. extracting from a "VNx4BI"-mode vector which has 4-bit precision on riscv. This patch adds a special case for that situation and sets bytenum to zero as well as bitnum to its proper value. It works for the riscv case because in all other situations we can align to a byte boundary. If x1 were 3 for some reason, however, the above assertion would still fail. I don't think this can happen for riscv as we only ever double the number of chunks for larger vector sizes but not sure about the general case. If there's another, correct way to work around feel free to suggest. Bootstrap/testsuite on aarch64 and x86 is running but I would be surprised if there were any changes as riscv is the only target that uses modes with precision < 8. Regards Robin gcc/ChangeLog: * expmed.cc (extract_bit_field_1): Handle bitnum with variable part less than BITS_PER_UNIT. --- gcc/expmed.cc | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/gcc/expmed.cc b/gcc/expmed.cc index e22e43c8505..1b0119f9cfc 100644 --- a/gcc/expmed.cc +++ b/gcc/expmed.cc @@ -1858,8 +1858,22 @@ extract_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, but is useful for things like vector booleans. */ if (MEM_P (op0) && !bitnum.is_constant ()) { - bytenum = bits_to_bytes_round_down (bitnum); - bitnum = num_trailing_bits (bitnum); + /* bits_to_bytes_round_down tries to align to a byte (BITS_PER_UNIT) + boundary and asserts that bitnum.coeffs[1] % BITS_PER_UNIT == 0. + For modes with precision < BITS_PER_UNIT this fails but we can + still extract from the first byte. */ + poly_uint16 prec = GET_MODE_PRECISION (outermode); + if (prec.coeffs[1] < BITS_PER_UNIT && bitnum.coeffs[1] < BITS_PER_UNIT) + { + bytenum = 0; + bitnum = bitnum.coeffs[0] & (BITS_PER_UNIT - 1); + } + else + { + bytenum = bits_to_bytes_round_down (bitnum); + bitnum = num_trailing_bits (bitnum); + } + poly_uint64 bytesize = bits_to_bytes_round_up (bitnum + bitsize); op0 = adjust_bitfield_address_size (op0, BLKmode, bytenum, bytesize); op0_mode = opt_scalar_int_mode ();