From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
Michael D Kinney <michael.d.kinney@intel.com>,
Liming Gao <gaoliming@byosoft.com.cn>,
Zhiguang Liu <zhiguang.liu@intel.com>
Subject: Re: [PATCH v3 1/1] MdePkg/Base.h: Simplify alignment expressions
Date: Tue, 16 May 2023 08:48:19 +0000 [thread overview]
Message-ID: <F7F936F6-D14E-4528-8383-5F251CDA352D@posteo.de> (raw)
In-Reply-To: <20230516021921.411852-1-pedro.falcato@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]
> On 16. May 2023, at 04:19, Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> Simplify ALIGN_VALUE and ALIGN_VALUE_ADDEND into simpler expressions.
>
> ALIGN_VALUE can simply be a (value + (align - 1)) & ~align
> expression, which works for any power of 2 alignment and generates
> smaller code sequences. For instance:
> ALIGN_VALUE(15, 16) = (15 + 15) & ~16 = 16
> ALIGN_VALUE(16, 16) = (16 + 15) & ~16 = 16
>
> Old codegen:
> movq %rdi, %rax
> negq %rax
> andl $15, %eax
> addq %rdi, %rax
>
> New codegen:
> leaq 15(%rdi), %rax
> andq $-16, %rax
>
> ALIGN_VALUE_ADDEND can simply use the negation of Value to get the
> addend for alignment, as, for instance:
> -15 & (16 - 1) = 1
> 15 + 1 = 16
>
> This change does not necessarily affect the end result, as the GCC and
> clang compilers were already able to see through things and optimize
> them into optimal instruction sequences, in the ALIGN_VALUE_ADDEND case.
>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>
> Cc: Zhiguang Liu <zhiguang.liu@intel.com>
> Cc: Marvin Häuser <mhaeuser@posteo.de>
> Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
> ---
> Changes:
> - Correct the ADDEND macro to use negation and not a binary NOT (thanks Liming!)
> MdePkg/Include/Base.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index 6597e441a6e2..a070593a360d 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -931,7 +931,7 @@ STATIC_ASSERT (ALIGNOF (__VERIFY_INT32_ENUM_SIZE) == sizeof (__VERIFY_INT32_ENUM
>
> @return Addend to round Value up to alignment boundary Alignment.
> **/
> -#define ALIGN_VALUE_ADDEND(Value, Alignment) (((Alignment) - (Value)) & ((Alignment) - 1U))
> +#define ALIGN_VALUE_ADDEND(Value, Alignment) ((-(Value)) & ((Alignment) - 1U))
>
> /**
> Rounds a value up to the next boundary using a specified alignment.
> @@ -945,7 +945,7 @@ STATIC_ASSERT (ALIGNOF (__VERIFY_INT32_ENUM_SIZE) == sizeof (__VERIFY_INT32_ENUM
> @return A value up to the next boundary.
>
> **/
> -#define ALIGN_VALUE(Value, Alignment) ((Value) + ALIGN_VALUE_ADDEND (Value, Alignment))
> +#define ALIGN_VALUE(Value, Alignment) (((Value) + ((Alignment) - 1U)) & ~(Alignment))
~((Alignment) - 1U)
Also, I'm quite sure this breaks for the case typeof(Value) > typeof(Alignment),typeof(Value) > unsigned int,typeof(Alignment) >= unsigned int (but always unsigned), this breaks. Assume Value is unsigned long long and Alignment is unsigned int. Then, the left-hand side will be unsigned long long. ~((Alignment) - 1U) will be unsigned int (regardless of whether or not we use 1 or 1U). Now, it will be promoted to unsigned long long for the evaluation of the AND operation, but because it is unsigned, it will not "sign-extend", thus discarding the high Bits of Value.
Best regards,
Marvin
>
> /**
> Adjust a pointer by adding the minimum offset required for it to be aligned on
> --
> 2.40.1
>
[-- Attachment #2: Type: text/html, Size: 4918 bytes --]
prev parent reply other threads:[~2023-05-16 8:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 2:19 [PATCH v3 1/1] MdePkg/Base.h: Simplify alignment expressions Pedro Falcato
2023-05-16 8:48 ` Marvin Häuser [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F7F936F6-D14E-4528-8383-5F251CDA352D@posteo.de \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox