From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 6EC303855595 for ; Mon, 15 May 2023 07:19:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6EC303855595 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-ej1-x62f.google.com with SMTP id a640c23a62f3a-965a68abfd4so2353668166b.2 for ; Mon, 15 May 2023 00:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684135153; x=1686727153; 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=8kRtQ+wOYEnzlM2eY3dbxSG9m4DpXKK7IZ/LzrQILfA=; b=LTehPl9wEI5onI0LRSzdGpmchLfZ5H51/eNnxOcvFvSR1hb5HfIUxapP3Rn0glLaIJ jcBfPVnsq4EYvRmiWeD4hOa6BjGLNA3h/Ov1n1OE5ene8sdZbvQRh7xXQcGc1a71tieE Rb3knvwqE310iB2TyW56EXMiXCi071zbR7P+FKIUQ6tahNZV3AC3ynjxzmMsL3emrAor SagjwSuHDbiVphQSjEdvoGJLgmVUqc2ReVauinHYTV6bUhG+G5gvzJOZ7b7dzyGBKEpt /TlZnArOsW6e2AOgCdiEaI3gsJnfXeyu58vQuidXiZkVz64ZnzcI9xf/Csk5ShRIMoNy tx4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684135153; x=1686727153; 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=8kRtQ+wOYEnzlM2eY3dbxSG9m4DpXKK7IZ/LzrQILfA=; b=de1ZvGbGnVt9pR9GK4OWbkuyPoIiDcS1QQQDDCTrbze0Mj5zCqoGYNRJFsyY826Of3 Q1LUbtMZO9d+qRF/iK8QZ5g/yAN/S6GLBMle9DqpyPrnZctcfRwXmu4O27haeAd2Q7Qi wUskujeQP606KuqKHGu0a19DrkL6Iq5vEot/hJatLfRS3IPDedJuQGDr54sz3+3tKKMX Mz6WWvcejuwYS0y0AzjPwTHrzS3/LmPNAVfm87MB2Ib9pXMpIpUbbhwXKF12X7wo9oOj SVGDEO9aB40zfsFFu28owfPlg1czuWdWfOBL90S145YQRWQVXZe3C+mswPWNPBDkJAh7 wbjg== X-Gm-Message-State: AC+VfDz+/ekwjcJkqTRJ9Ah3du9hudJz719EaEEuNEvAWZ3WZPJyxqH5 Bwo/0NFVKZqtRTZIIovAAQM= X-Google-Smtp-Source: ACHHUZ5wISfuWkoYPli4jy0q4al/1jdjmkRiGuqRXndbmoRYiBrfhnf5atLjxCxb9x04SBrqbXxkpw== X-Received: by 2002:a17:907:d1c:b0:966:5912:c4b with SMTP id gn28-20020a1709070d1c00b0096659120c4bmr24780447ejc.76.1684135151713; Mon, 15 May 2023 00:19:11 -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 l21-20020a170906a41500b00965c6c63ea3sm9041687ejz.35.2023.05.15.00.19.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 00:19:11 -0700 (PDT) Message-ID: Date: Mon, 15 May 2023 09:19:10 +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: Kito Cheng , "juzhe.zhong@rivai.ai" References: <20230513114421.196081-1-juzhe.zhong@rivai.ai> <9749BBE19D80DC01+2023051508355391896637@rivai.ai> From: Robin Dapp In-Reply-To: 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: Hi, we need to discern what we want to achieve here. The goal might be to prevent the vectorizer from performing peeling or versioning for alignment. I realize the peeling code looks ugly but it's actually for a good cause when the target does not support misaligned vector access or only with severe penalty. So while I was still commenting on the other V1 patch I realized that V2 is already in now :) > return TYPE_ALIGN (TREE_TYPE (type)); I'm not sure this is what we want or rather what the hardware wants. The preferred alignment of a VNx4SI (or larger) is 32 bit/4 bytes then - even 1 byte for a QI vector? Of course, we don't peel for alignment then anymore but we might actually want to, depending on the hardware. I mean as a temporary workaround it might be acceptable but do we actually need to get rid of the peeling code? If the hardware supports unaligned access without penalty we should specify in the vectorization costs e.g. case unaligned_load: case unaligned_store: return 1; (Your "return 1" for riscv_builtin_vectorization_cost will do that as well of course). and the peeling cost check should do the rest (i.e. nothing :) ). So I'd much rather prefer that over the current approach as it is more localized and will need an mtune-related approach later anyway. Regards Robin