From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id CD8503858D32 for ; Thu, 25 May 2023 11:10:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD8503858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6af812703b6so554512a34.1 for ; Thu, 25 May 2023 04:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1685013047; x=1687605047; h=mime-version:user-agent:message-id:in-reply-to:date:errors-to :references:organization:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qiC8d60wnq0Bp5zUXbZjQ7tM/qUJv/Zh5WIyfudF7lU=; b=LiVXnees7S5uPO0YDwOiiHdYXW1X3MDkyNf0lWwkIC4y5AeoO2n8UkWZwXttlQyhRJ 9KtCEjJQ4lJ7ROa7+hiOxEq4Xcd09acj4iPn3LWkx47k4+4Dk9Gr1osQuKwA0GhsVZQn b8fiJC0Cyd0WSnF6E5IOFHQLi/cQ1uYuBApjdBn40ZwlSq7cGwX/5nWyQXkXVfu8iSzZ sit5haz6qzmtGz3VaBmhHBeYq4iUOl6ANk1yS6U+cPNf5O9BE47v+01xPBGhWE60WHWI VkMP3HdPNlL7pnXURmEd6Rsi2XbuaFuXERp5Um+WresSeO+hPg0gh+QDgbrdBQq6Deu5 Z1XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685013047; x=1687605047; h=mime-version:user-agent:message-id:in-reply-to:date:errors-to :references:organization:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qiC8d60wnq0Bp5zUXbZjQ7tM/qUJv/Zh5WIyfudF7lU=; b=VmBoHso3gFvKJ6Ggc3rHalsY9L7cElJNVTFetM5AhD8Tn1anJaeT/pyobGOQrxxFkn piVQwIiXRKzU57bSuZArMG6jzny6W/OjxupzVQCBC3OF6a/yx/wt81lUYZdzgWEikAgm 9GWFXtkEurDq/dcH//GwjfZDtCFCFKt8CKmTCgcDAg67q8ol6qfI2U5avog7c73Q/o/K IB0CUNKNfUcUZ1pSAb+TpcPhhOX/rE/WN7OBI/654cBhHvxc5Hew6+svLE+DkUZ2I8kk Keci2ofshnQy9a6jvY7KoTznizgcI3b79WB9lYGh1dV5EZVRqliqhUb6JWMOqfbV+/LM Szyg== X-Gm-Message-State: AC+VfDzo0t8AH1WbMCMgvJDc7i+yT2eaxYnI4TGSFOHFYl7rLNXIPaop mWUkWcVJNHnehOpCq+VhpcO/fQ== X-Google-Smtp-Source: ACHHUZ4kYEMkoKjoVsOvuJYWlELn4bRGBFALKbBOVoh2yg1X/RCy7lydSqF4OqqnP/Jeh61QcIPMjg== X-Received: by 2002:a9d:73c4:0:b0:6aa:f626:841c with SMTP id m4-20020a9d73c4000000b006aaf626841cmr9427163otk.7.1685013047055; Thu, 25 May 2023 04:10:47 -0700 (PDT) Received: from free.home ([2804:7f1:2080:6383:46d9:ede8:ee97:8cc0]) by smtp.gmail.com with ESMTPSA id s15-20020a056830148f00b006acd6e5b56bsm508723otq.15.2023.05.25.04.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 04:10:46 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 34PBAbS23674100 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 25 May 2023 08:10:38 -0300 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, "H.J. Lu" , Jan Hubicka , Uros Bizjak Subject: Re: [PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Thu, 25 May 2023 08:10:37 -0300 In-Reply-To: (Richard Biener's message of "Thu, 25 May 2023 12:49:20 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On May 25, 2023, Richard Biener wrote: > I mean we could do what RTL expansion would do later and do > by-pieces, thus emit multiple loads/stores but not n loads and then > n stores but interleaved. That wouldn't help e.g. gcc.dg/memcpy-6.c's fold_move_8, because MOVE_MAX and MOVE_MAX_PIECES currently limits inline expansion to 4 bytes on x86 without SSE, both in gimple and RTL, and interleaved loads and stores wouldn't help with memmove. We can't fix that by changing code that uses MOVE_MAX and/or MOVE_MAX_PIECES, when these limits are set too low. I'm also concerned that doing more such expansion in gimple folding would be reversed in later gimple passes. That's good in that it would enable efficient rtl movmem/cpymem instruction selection, but it's not clear to me that there would generally be benefits to such early open-coding in gimple. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about