[llvm] [Docs] Update frontend perfomance tips about loads/stores (PR #83833)

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 4 05:30:24 PST 2024


https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/83833

>From 660311604d337d71c1d9f1b09bcfb4bc653c9746 Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Mon, 4 Mar 2024 12:51:36 +0100
Subject: [PATCH 1/2] Update frontend perfomance tips about loads/stores

---
 llvm/docs/Frontend/PerformanceTips.rst | 36 ++++++++++++++++++++------
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index dfa3ccdd1ddd1e..671c77c9d63a80 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -64,16 +64,36 @@ SSA is the canonical form expected by much of the optimizer; if allocas can
 not be eliminated by Mem2Reg or SROA, the optimizer is likely to be less
 effective than it could be.
 
-Avoid loads and stores of large aggregate type
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Avoid creating values of aggregate type
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Avoid creating values of :ref:`aggregate types <t_aggregate>` (i.e. structs and
+arrays). In particular, avoid loading and storing them, or manipulating them
+with insertvalue and extractvalue instructions. Instead, only load and store
+individual fields of the aggregate.
+
+There are some exceptions to this rule:
+
+* It is fine to use values of aggregate type in global variable initializers.
+* It is fine to return structs, if this is done to represent the return of
+  multiple values in registers.
+* It is fine to work with structs returned by LLVM intrinsics, such as the
+  ``with.overflow`` family of intrinsics.
+* It is fine to use aggregate *types* without creating values. For example,
+  they are commonly used in ``getelementptr`` instructions or attributes like
+  ``sret``.
+
+Avoid loads and stores of non-byte-sized types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Avoid loading or storing non-byte-sized types like ``i1``. Instead,
+appropriately extend them to the next byte-sized type.
 
-LLVM currently does not optimize well loads and stores of large :ref:`aggregate
-types <t_aggregate>` (i.e. structs and arrays).  As an alternative, consider
-loading individual fields from memory.
+For example, when working with boolean values, store them by zero-extending
+``i1`` to ``i8`` and load them by loading ``i8`` and truncating to ``i1``.
 
-Aggregates that are smaller than the largest (performant) load or store
-instruction supported by the targeted hardware are well supported.  These can
-be an effective way to represent collections of small packed fields.
+If you do use loads/stores on non-byte-sized types, make sure that we *always*
+use those types. For example, do not first store ``i8`` and then load ``i1``.
 
 Prefer zext over sext when legal
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>From 23d06fe3cd94711eab0b58f6680ae45c2cc30a2d Mon Sep 17 00:00:00 2001
From: Nikita Popov <github at npopov.com>
Date: Mon, 4 Mar 2024 14:30:18 +0100
Subject: [PATCH 2/2] Update llvm/docs/Frontend/PerformanceTips.rst

Co-authored-by: Ralf Jung <post at ralfj.de>
---
 llvm/docs/Frontend/PerformanceTips.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index 671c77c9d63a80..289106cd1e28ea 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -92,7 +92,7 @@ appropriately extend them to the next byte-sized type.
 For example, when working with boolean values, store them by zero-extending
 ``i1`` to ``i8`` and load them by loading ``i8`` and truncating to ``i1``.
 
-If you do use loads/stores on non-byte-sized types, make sure that we *always*
+If you do use loads/stores on non-byte-sized types, make sure that you *always*
 use those types. For example, do not first store ``i8`` and then load ``i1``.
 
 Prefer zext over sext when legal



More information about the llvm-commits mailing list