From 0a98268313d4c145d61c0515ef58461770c604dd Mon Sep 17 00:00:00 2001 From: matheusaaguiar <95899911+matheusaaguiar@users.noreply.github.com> Date: Wed, 1 Nov 2023 14:56:32 -0300 Subject: [PATCH] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: r0qs Co-authored-by: Kamil Śliwak --- docs/internals/optimizer.rst | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/docs/internals/optimizer.rst b/docs/internals/optimizer.rst index bd3bac48e024..08c968ec5573 100644 --- a/docs/internals/optimizer.rst +++ b/docs/internals/optimizer.rst @@ -22,8 +22,8 @@ the function calls. Similarly, if a function is side-effect free and its result is multiplied by zero, you can remove the function call completely. -The codegen-based optimizer currently consists of a single step that makes the compiler use unchecked -arithmetic when generating code for the counter variable increment of certain ``for`` loops. +The codegen-based optimizer currently consists of a single step, wherein the compiler utilizes unchecked arithmetic +when generating code for incrementing the counter variable in specific ``for`` loops. Currently, the parameter ``--optimize`` activates the opcode-based optimizer for the generated bytecode and the Yul optimizer for the Yul code generated internally, for example for ABI coder v2. @@ -1397,21 +1397,21 @@ which makes the compiler automatically generate unchecked arithmetic code that increments the counter variable of a `for` loop. The single step of this module, which is explained next, avoids wasting gas unnecessarily, by identifying some conditions that guarantee that the counter variable cannot overflow. This eliminates -the need to use a explicit unchecked arithmetic block inside the loop body to -increment the counter variable +the need to use an explicit unchecked arithmetic block inside the loop body to +increment the counter variable. Unchecked Loop Increment ------------------------ Introduced in solidity ``0.8.22``, this optimizer step is concerned with identifying -the conditions under which the code of a ``for`` loop counter can be incremented +the conditions under which the ``for`` loop counter can be incremented without overflow checks. The optimization is always turned on by default and can only be turned off by setting the ``simpleCounterForLoopUncheckedIncrement`` flag to false inside ``settings.optimizer.details`` in Standard JSON input. It is not possible to disable it using the command-line interface. This optimization is **only** applied to ``for`` loops which use built-in operators ``<`` in the -condition and (postfix/prefix) ``++`` in the lopp expression with the general form: +condition and (postfix/prefix) ``++`` in the loop expression with the general form: .. code-block:: solidity @@ -1419,15 +1419,16 @@ condition and (postfix/prefix) ``++`` in the lopp expression with the general fo // variable i is not modified in the loop body } -In many cases, the comparison is guaranteed to ensure that the counter variable -never overflows. The precise conditions are listed and explained as follows: +The condition and the fact that the counter variable is only ever incremented +guarantee that it never overflows. +The precise requirements for the loop to be eligible for the optimization are as follows: - The loop condition is a comparison of the form ``i < x``, for a local counter variable ``i`` and an expression ``x``. - The built-in operator ``<`` is necessarily used in the loop condition. User-defined operators are **not** eligible. - The loop expression is a prefix or postfix increment of the counter variable, i.e, ``i++`` or ``++i``. - The loop counter is a local declared variable of a built-in integer type. - The loop counter is **not** modified neither in the body nor in the condition. - - The comparison is performed on the same type of the loop counter, meaning that the type of the right-hand-side expression is implicitly convertible to the type of the counter, such that the latter is not implicitly widened before comparing. + - The comparison is performed on the same type as the loop counter, meaning that the type of the right-hand-side expression is implicitly convertible to the type of the counter, such that the latter is not implicitly widened before comparing. To clarify the last condition, consider the next example: