From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 195DB385841E for ; Mon, 15 May 2023 08:58:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 195DB385841E 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-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-50be17a1eceso23142715a12.2 for ; Mon, 15 May 2023 01:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684141137; x=1686733137; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RMjqYJVWPBZUeLgt1QzZ44IFChjNVZsNmPTICqeQaz4=; b=IYGzgcL8R+9bK7/bNZQjP+JHTZE+2D/BnXOkjZeVdpFWHqb7p03c2s0WQxXJhGJaOX vpMCAWDGBuweLlKvFWbhrjOtDBsjy1Gt+D//i4q1N9krpyEhHDZ6HxeyZiOEuYnjXq+y h7Nb6BfKD77xva5Rskd07DmNSL2wJ6Hr0mS5eBuPRkd+xlgXgg1mD1UMesY6ZPrGG9Hp IA8C+HNL6ueXbF7qrDvAxqeW6/yNmwcMpSM89e9WStWsUrYvzUDRrM/+Nu6JrlE1sae6 FHff0pk3A4+N7+T801dcUhCUrr2TJqb9tscDih3S79p6enJ+vIvGA83QDNmqO6fJ5KYr tbAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684141137; x=1686733137; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RMjqYJVWPBZUeLgt1QzZ44IFChjNVZsNmPTICqeQaz4=; b=boJ/QmRg4YfqYnuRQ3WeYLULOrNQZvq0yEfHdd+NoTMQQBptBysYtqlG6hTLGAKWf7 iyxVtUcL6m4+9iWOgIHYA0pZv7IJngn6FAfM3mM83JpFzorpljTYhol2H1eeJoO+P62Q 7q4v3ycXIruvf0wxpVZcO5w9fqOyJNglS4HhNA3RuScT98WTfcf5vIr/hbns5Wt1LI48 sTKkBDJi98yDxPG+fwB3w2vfg6EwNWtEQgjoQ5YY2zROXtqGhgEk285EO1OCG5Kgp8WS 6iDitp7VtKjwPMNyhAANx42SxEEO2d05WF2QVAmQ8gAN4urRn7J17EPBv1emAptLDhAp ILeA== X-Gm-Message-State: AC+VfDyyNDKfwmje+G+cwpjXCRvbEbSnLPQLEDYoJPYILLEWeVvpHHjd plmfXm9AR9khGjWTKk4fV9E= X-Google-Smtp-Source: ACHHUZ5ZcJjwtZGFHqEQePDhLn7m0+YFPUJy5KG0shGjg70UOR/cnwo/GUstwRVheq7oNM0dOz4+dA== X-Received: by 2002:a17:906:da87:b0:966:3c82:4a97 with SMTP id xh7-20020a170906da8700b009663c824a97mr26626317ejb.35.1684141136592; Mon, 15 May 2023 01:58:56 -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 kw3-20020a170907770300b0096621c999c6sm9178978ejc.79.2023.05.15.01.58.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 01:58:56 -0700 (PDT) Message-ID: <07b815ad-a607-9b59-14c5-b0b0180d103b@gmail.com> Date: Mon, 15 May 2023 10:58:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: rdapp.gcc@gmail.com, gcc-patches , palmer , jeffreyalaw Subject: Re: [PATCH] RISC-V: Support TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT to optimize codegen of RVV auto-vectorization Content-Language: en-US To: "juzhe.zhong@rivai.ai" , "Kito.cheng" , "richard.sandiford" References: <20230513114421.196081-1-juzhe.zhong@rivai.ai> <9749BBE19D80DC01+2023051508355391896637@rivai.ai> <132E881DE80F1875+2023051516101569689363@rivai.ai> From: Robin Dapp In-Reply-To: <132E881DE80F1875+2023051516101569689363@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.8 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,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: > After this patch, RVV GCC by default support alignment of RVV modes > according to riscv-modes.def. In riscv-modes.def, we define each RVV > modes are element align which is aligned to RVV ISA spec. > > If you want to support other alignment, you should add tunning info > for this in the future. And the default behavior in case of alignment > which is already in this patch should not be changed in the future. We're changing the preferred_vector_alignment hook, not the vector_alignment hook. The way I see it, we will never peel for alignment when setting the preferred_alignment to the alignment of a single element, no matter the cost of misaligned loads/stores. Is the idea then to adjust the preferred_alignment hook depending on mtune? IMHO it's much more "natural" to set the vectorization costs according to mtune (done anyway at some point), not change the preferred_alignment and let the vectorizer decide whether is has enough information on whether to peel or not. Maybe Richard can comment here on why the vector_alignment_preferred hook was originally introduced or what wasn't possible without it (i.e. why not go via costs). At some point the vectorizer would peel even if the costs were low for misaligned accesses but that had already been fixed before the hook was introduced. And ABI-wise (and that's what the V spec documents) we are already safe by using MIN (128, TYPE_SIZE (type)). We could probably even lower that? Regards Robin