On Tue, Nov 21, 2017 at 01:40:17PM +, Ard Biesheuvel wrote:
> Most crypto drivers involving kernel mode NEON take care to put the code
> that actually touches the NEON register file in a separate compilation
> unit, to prevent the compiler from reordering code that preserves or
> restores the N
On Wed, Nov 22, 2017 at 12:04:58PM +, Mark Rutland wrote:
> On Wed, Nov 22, 2017 at 10:12:17AM +, Ard Biesheuvel wrote:
> > On 22 November 2017 at 10:05, Alex Matveev wrote:
> > > This is better than my simple fix, thank you.
> > >
> > > Out of curiosity, why doesn't NEON code use barrier(
On Wed, Nov 22, 2017 at 10:12:17AM +, Ard Biesheuvel wrote:
> On 22 November 2017 at 10:05, Alex Matveev wrote:
> > This is better than my simple fix, thank you.
> >
> > Out of curiosity, why doesn't NEON code use barrier() to prevent
> > reordering?
>
> Because barrier() affects ordering of
On 22 November 2017 at 10:05, Alex Matveev wrote:
> This is better than my simple fix, thank you.
>
> Out of curiosity, why doesn't NEON code use barrier() to prevent
> reordering?
>
Because barrier() affects ordering of memory accesses, not register accesses.
> On Tue, 21 Nov 2017 13:40:17 +000
This is better than my simple fix, thank you.
Out of curiosity, why doesn't NEON code use barrier() to prevent
reordering?
On Tue, 21 Nov 2017 13:40:17 +
Ard Biesheuvel wrote:
> Most crypto drivers involving kernel mode NEON take care to put the
> code that actually touches the NEON registe
Checked for transcription errors, calling convention, and removal of
temporary locals. LGTM.
Reviewed-By: Nick Desaulniers
On Tue, Nov 21, 2017 at 5:40 AM, Ard Biesheuvel
wrote:
> Most crypto drivers involving kernel mode NEON take care to put the code
> that actually touches the NEON register
