[lkml]   [2022]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)

On 12/15/22 07:33, Richard Henderson wrote:
> On 12/15/22 04:28, Florian Weimer via Libc-alpha wrote:
>> * Björn Töpel:
>>>> For SVE, it is in fact disabled by default in the kernel.  When a
>>>> thread
>>>> executes the first SVE instruction, it will cause an exception, the
>>>> kernel
>>>> will allocate memory for SVE state and enable TIF_SVE. Further use
>>>> of SVE
>>>> instructions will proceed without exceptions.  Although SVE is
>>>> disabled by
>>>> default, it is enabled automatically.  Since this is done
>>>> automatically
>>>> during an exception handler, there is no opportunity for memory
>>>> allocation
>>>> errors to be reported, as there are in the AMX case.
>>> Glibc has an SVE optimized memcpy, right? Doesn't that mean that pretty
>>> much all processes on an SVE capable system will enable SVE
>>> (lazily)? If
>>> so, that's close to "enabled by default" (unless SVE is disabled system
>>> wide).
>> Yes, see sysdeps/aarch64/multiarch/memcpy.c:
>>    static inline __typeof (__redirect_memcpy) *
>>    select_memcpy_ifunc (void)
>>    {
>>      INIT_ARCH ();
>>         if (sve && HAVE_AARCH64_SVE_ASM)
>>        {
>>          if (IS_A64FX (midr))
>>            return __memcpy_a64fx;
>>          return __memcpy_sve;
>>        }
>>         if (IS_THUNDERX (midr))
>>        return __memcpy_thunderx;
>>         if (IS_THUNDERX2 (midr) || IS_THUNDERX2PA (midr))
>>        return __memcpy_thunderx2;
>>         if (IS_FALKOR (midr) || IS_PHECDA (midr))
>>        return __memcpy_falkor;
>>         return __memcpy_generic;
>>    }
>>    And the __memcpy_sve implementation actually uses SVE.
>> If there were a prctl to select the vector width and enable the vector
>> extension, we'd have to pick a width in glibc anyway.
> There *is* a prctl to adjust the SVE vector width, but glibc does not
> need to select because SVE dynamically adjusts to the currently
> enabled width.  The kernel selects a default width that fits within
> the default signal frame size.
> The other thing of note for SVE is that, with the default function ABI
> all of the SVE state is call-clobbered, which allows the kernel to
> drop instead of save state across system calls.  (There is a separate
> vector function call ABI when SVE types are used.)

For the RV psABI, it is similar - all V regs are
caller-saved/call-clobbered [1] and syscalls are not required to
preserve V regs [2]
However last I checked ARM documentation the ABI doc seemed to suggest
that some (parts) of the SVE regs are callee-saved [3]

> So while strcpy may enable SVE for the thread, the next syscall may
> disable it again.

Next syscall could trash them, but will it disable SVE ? Despite
syscall/function-call clobbers, using V in tight loops such as mem*/str*
still is a win.

Sec 6.1.3 ".... In other cases it need only preserve the low 64 bits of

 \ /
  Last update: 2022-12-15 19:57    [W:0.234 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site