shamoe has quit [Quit: Connection closed for inactivity]
<courmisch>
sorear: libs are going to assume that V is enabled. If you disable V with the prctl() you really need tight control over all your code
<courmisch>
I mean libs check for HWCAP and/or hwprobe, not the prctl
<courmisch>
conchuod: there's a kernel in k230sdk, but I don't know where from, since it's a copy-paste with no git history
<sorear>
you don't have to check the prctl if you're using HWCAP because (t-head vendor kernel bugs notwithstanding) the HWCAP is only set if the prctl is enabled, unlike hwprobe which is unaffected by prctl
<courmisch>
sorear: I don't think libs are going to care about that subtlety
<sorear>
"libs are going to assume V is enabled / disabling V with prctl is unsupported unless you have a closed system" good to hear if true. how much support does this position have?
<courmisch>
especially if they need hwprobe anyway for some other stuff like Zbb or Zvfh
<sorear>
more authority than your own as a random ffmpeg commiter?
<courmisch>
it's just how every other arch does it. it's also how RISE recommends it for RV
<courmisch>
and I didn't write that document
<courmisch>
well other archs use hwcap or cpuid-type things, not some prctl
<sorear>
has anyone looked at the gcc compile time impact of xtheadv? gcc-11 to gcc-snapshot on the debian buildfarm is 1 day to 7 days, probably most of that is arch-independent features but I'm still concerned about the impact of vectorization
<courmisch>
you think their optimisation passes take forever to compile?
esv has quit [Remote host closed the connection]
esv has joined #riscv
agent314 has joined #riscv
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
jacklsw has quit [Quit: Back to the real world]
heat_ has quit [Remote host closed the connection]
<courmisch>
(and I was forced to use those nonstandard names for CPU flags, so don't ask me why)
<palmer>
ya, so hwprobe is the way to do that -- the prctl for V is a slightly different thing (it's technically an ABI break, so we're leaving it up to distros to decide if they care)
<courmisch>
unlord: I have patches to make it build with off-the-shelf cross-compiler. trimming the makefiles down to just SPL+SBI+uboot+kernel not so succesful
<courmisch>
seems I was a little heavy handed and deleted some device tree sources
<unlord>
Wow
<courmisch>
also my Github account no longer exists, so don't ask me to push there
<unlord>
off the grid, cool
agent314 has quit [Ping timeout: 256 seconds]
agent314 has joined #riscv
<courmisch>
if anybody was curious what happens when you don't agree to updated ToS
felixonmars has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
felixonmars has joined #riscv
<courmisch>
are there any plans to have __builtin_ffs and friends pick Zbb at run-time?
aburgess has quit [Ping timeout: 268 seconds]
stolen has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
ZipCPU has quit [Ping timeout: 260 seconds]
<heat_>
courmisch, i would not be surprised if the cost of a function call takes away any wins from having specific instructions for that
<courmisch>
heat_: for min/max, definitely. For ctz/clz/popcount though
prabhakar has quit [Ping timeout: 255 seconds]
<heat_>
it's not *exactly* the same thing, but i've heard that arm64 outline atomics (which do a function call + branch if an extension is present) have a nasty penalty due to the function call itself
<courmisch>
heat_: outline atomics are trying to be scalable, not fast, AFAIU
<courmisch>
and they do the runtime check every call instead of using ifunc or something to dispatch directly to the right function
ZipCPU has joined #riscv
agent314 has quit [Ping timeout: 255 seconds]
agent314 has joined #riscv
<palmer>
courmisch: I think that would happen via glibc_hwcaps, but we got hung up on which targets to support
<palmer>
(unless those are in libgcc.a, in which case I don't think anyone's working on it right now. The dynamic function multiversioning stuff would probably be the way to go, but I think that's a bit of a way off)
agent314 has quit [Quit: No Ping reply in 180 seconds.]
prabhakar has joined #riscv
prabhakarlad has joined #riscv
agent314 has joined #riscv
heat has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
sakman has quit [Quit: Leaving]
geertu has quit [Quit: leaving]
motherfsck has quit [Read error: Connection reset by peer]
davidlt has quit [Ping timeout: 264 seconds]
<courmisch>
ookay, I can now build the K230 bootloader and kernel and not the crap that went with it
<courmisch>
on a Debian-amd64 unstable
BootLayer has quit [Quit: Leaving]
Jackneill has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
aburgess has joined #riscv
motherfsck has joined #riscv
sakman has joined #riscv
mlw has quit [Ping timeout: 264 seconds]
<heat>
courmisch, ofc they want scalability but given that the fast path (for spinlocks, mutexes, any sort of cmpxchg loop really) is a usually lack of contention, you don't want to pay the cost
<sorear>
you'd think that in the post-spectre world there'd be a lot more emphasis on global boolean flags and 2-way jumps, with the best path inline
kailo has joined #riscv
jobol has quit [Remote host closed the connection]
<heat>
sorear, what does spectre have to do with that?
<sorear>
sometimes people consider indirect branch prediction a security risk
<heat>
well ifunc is completely transparent, it's just a GOT entry you conditionally set AFAIK
<heat>
so to get rid of indirect calls you'd need to get rid of shared libraries in general
<heat>
fwiw, I think a lot could be done using binary patching, even in userspace. like linux ALTERNATIVES but for userspace, and a daemon would see CPU changes and re-patch binaries
danilogondolfo has quit [Remote host closed the connection]
geertu has joined #riscv
averymt_ has joined #riscv
averymt has quit [Ping timeout: 276 seconds]
averymt_ is now known as averymt
averymt has quit [Ping timeout: 256 seconds]
averymt has joined #riscv
wingsorc has quit [Read error: Connection reset by peer]