14:09 <ardb> marex: any idea whether the exynos emulation in QEMU works?

16:10 <marex> ardb: um ... me ? wrong person I think

16:10 <marex> ardb: I don't know whether armbru is here

16:11 <ardb> marex: oops sorry

16:11 <marex> ardb: who were you looking for anyway ?

16:12 <marex> the 4210 looks like it has been unmaintained for a bit

16:12 <ardb> marek :-)

16:12 <ardb> but not you

16:12 <marex> there are many

16:12 <ardb> so it appears

16:12 <marex> heh

16:12 <Xogium> there must be a clone() function somewhere that clones marex all over the place

16:13 <marex> ardb: ah, szyprowski, look a bit further north

16:13 <marex> and I recall seeing him on irc I think

16:14 <marex> ardb: try mszyprow

16:23 <geertu> Xogium: Yeah, they cloned marex for Mission Impossible ;-)

16:24 <headless> geertu: Mission Impossible as staying at home for a year? :-)

16:32 <ardb> marex: thanks

16:33 <marex> ardb: you're welcome

16:36 <headless> marex: howdy?

18:25 <ndesaulniers> ardb + arnd : do either you have thoughts on this proposed style of change (before I finish it for the remaining functions)? https://github.com/ClangBuiltLinux/linux/issues/496#issuecomment-995253880. arnd mentioning splitting the interface in half for when the pointers were equivalent, but I don't quite follow the recommendation.

19:31 <arnd> ndesaulniers: I'd say we don't need to worry about the two-input case of both inputs being the same ;-)

19:31 <arnd> What I was thinking is that we'd change the exported interface to actually use __restrict

19:32 <ndesaulniers> arnd: ack, I have the full patch ready, just triple checking the before+after disassembly. Worst case will just send to the patch as an RFC

19:32 <ndesaulniers> the exported interface?

19:32 <ndesaulniers> then it's on those callers to ensure there's no overlaps

19:32 <arnd> I mean the interface that drivers would use

19:32 <ndesaulniers> yeah

19:32 <arnd> looking at include/asm-generic/xor.h, it seems that this one already uses __restrict...

19:40 <ndesaulniers> arnd: huh? __restrict does not appear in include/asm-generic/xor.h

19:54 <ndesaulniers> arnd: sent you a patch, please let me know your thoughts on it

19:58 <ndesaulniers> sigh, at least GCC can let you know if you're doing something obviously stupid with __restrict https://github.com/llvm/llvm-project/issues/52824

20:03 <ndesaulniers> I'm curious about the case of partial overlap though, since **I think** __restrict means that the pointed to objects don't overlap at all, while the NEON code only requires that they don't overlap by 8 * 4B regs

20:04 <ndesaulniers> ah, `-Wrestrict` wont warn about that, so nvm my concern.

21:16 <arnd> ndesaulniers: hah, I had a patch in my tree labeled as [REVISIT] ;-)

21:19 <ndesaulniers> arnd: right, didn't you have a thread discussing such change with Linus?

21:19 <arnd> ndesaulniers: no, I think we discussed that in person the last time we had a conference in early 2020

21:26 <arnd> https://www.irccloud.com/pastebin/Yxl4pip7/

21:26 <arnd> ndesaulniers: I'm trying to find all the callers at the moment, to see which ones actually overlap. These are the only files I found ^

21:28 <arnd> Unfortunately, the xor_blocks/async_xor interfaces are not easily annotated with __restrict

21:28 <ndesaulniers> arnd: well there's probably obvious overlap where the same parameter is passed twice (that `-Wrestrict` w/ gcc should report, not sure if the kernel is `-Wrestrict` clean already or not), but then non-obvious cases where at runtime two different variables slightly overlap by 32B; that's the case I'm worried about. It might not ever actually happen. Also, ardb suggested using arch/arm64/lib/xor-neon.c which uses intrinsics.

21:29 <arnd> ndesaulniers: I'm fairly sure the partial overlap never happens, it's either in-place or non-overlapping

21:29 <arnd> what I'd like to do though is to have separate driver interfaces for those two cases and annotate them in a way that makes it impossible to confuse

21:38 <arnd> ndesaulniers: I only now saw your patch, I don't see what it does yet: where do you actually add the __restrict to make it work?

21:39 <ndesaulniers> arnd: arch/arm/lib/xor-neon.c.

21:42 <arnd> ah, so you just duplicate (some of) the code to make it work for arm

21:46 <arnd> ndesaulniers: since you are just checking the overlap within a few bytes, would it make more sense to use __attribute__((aligned())) instead of __restrict?

21:47 <arnd> as far as I can tell, the input and output is always aligned to a large enough power of two to make that true, and this might allow additional optimizations

21:47 <ndesaulniers> can you use that on a pointer to specify that it must be a multiple of 32B?

21:48 <arnd> I don't see why not

21:51 <arnd> there is also an __attribute__((warn_if_not_aligned (ALIGNMENT)), though I don't think it would help here, since the drivers don't mark their pointers as aligned

21:57 <arnd> hmm, the async code has an alignment check in it, but it falls back to xor_blocks() if the pointers are misaligned, so maybe we can't rely on the alignment after all