Re: [PATCH v2 1/2] lib/xor: make xor prototypes more friendely to compiler vectorization

From: Nick Desaulniers <ndesaulniers@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au,
	Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH v2 1/2] lib/xor: make xor prototypes more friendely to compiler vectorization
Date: Mon, 31 Jan 2022 10:13:02 -0800	[thread overview]
Message-ID: <CAKwvOdmW6cxMT_X9T+O98x55MY_b0zCaJWArU4OfTay6Ceyovg@mail.gmail.com> (raw)
In-Reply-To: <20220129224529.76887-2-ardb@kernel.org>

On Sat, Jan 29, 2022 at 2:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Modern compilers are perfectly capable of extracting parallelism from
> the XOR routines, provided that the prototypes reflect the nature of the
> input accurately, in particular, the fact that the input vectors are
> expected not to overlap. This is not documented explicitly, but is
> implied by the interchangeability of the various C routines, some of
> which use temporary variables while others don't: this means that these
> routines only behave identically for non-overlapping inputs.
>
> So let's decorate these input vectors with the __restrict modifier,
> which informs the compiler that there is no overlap. While at it, make
> the input-only vectors pointer-to-const as well.
>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Thanks for the patch!
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

I like how you renamed the parameters in
arch/powerpc/include/asm/xor_altivec.h, arch/powerpc/lib/xor_vmx.h,
and arch/powerpc/lib/xor_vmx_glue.c.  It's not befitting for the
suffix _in to be used when the first param is technically more of an
"inout" param.  Though, you might also want to update the parameter
names in arch/powerpc/lib/xor_vmx.c.
-- 
Thanks,
~Nick Desaulniers