<daurnimator>
andrewrk: how do we make sure the functions in compiler-rt don't get optimized into function calls into compiler-rt?
g_w1 has joined #zig
<andrewrk>
there is a backend-specific answer to that question
<andrewrk>
for llvm it's nobuiltin. for our own backend we can take whatever strategy we want
<daurnimator>
andrewrk: further context, considering #7265, on some targets I imagine e.g. sincos would be a call to hardware for sin and cos. while on others sin and cos might be a call to sincos which is backed by a hardware instruction itself.
<daurnimator>
or is that assumption just totally incorrect?
<daurnimator>
andrewrk: so we can build the entire compiler-rt object with nobuiltin? or do we need our own function attribute `nobuiltin(true)`?
<g-w1>
iirc, at least on x86_64, the libc versions of trig functions are actually faster than the hardware ones for some reason
<andrewrk>
tbh I don't think we need to do anything until the problem actually manifests. I'm not worried about being able to solve it if it starts happening
<andrewrk>
currently we have a flag in the compiler implementation that is set to true when we are building compiler-rt symbols
st4ll1 has quit [Remote host closed the connection]
st4ll1 has joined #zig
<daurnimator>
I'm sort of afraid of it coming up only on certain optimization levels with certain cpu feature sets.
<andrewrk>
fengb, what's the wasm equivalent command of `readelf -s` but for a wasm object?
<daurnimator>
there's a wasm-objdump
<ifreund>
wasm2wat can also be useful
<andrewrk>
daurnimator, if you copy the memcpy source code from zig's compiler-rt into a separate file and rename the function and run optimizations, it will optimize into a call to memcpy. but within compiler-rt the function's body is preserved
<andrewrk>
looks like llvm pays attention to the symbol name
<daurnimator>
andrewrk: I'm struggling to get a zig version that optimizes to `__memcpy4`
a92 has joined #zig
xackus__ has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
xackus_ has quit [Read error: Connection reset by peer]
<andrewrk>
huh. LLD lets you pass a shared object as a positional argument for x86_64 but not for aarch64
a92 has quit [Quit: My presence will now cease]
<ky0ko>
is there some trick to getting zig to use frameworks with C headers on macOS? linkSystemLibrary/linkFramework in my build.zig seem to be doing nothing to get it to find the C headers
<ky0ko>
i'm just trying to get something to work with SDL2
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
you gotta add the framework directory manually
<andrewrk>
(as a workaround for now. that's not the intended user experience)
xackus has joined #zig
xackus__ has quit [Ping timeout: 260 seconds]
<ky0ko>
what do you mean by this? `exe.addFrameworkDir("/Library/Frameworks");` sort of deal?
<andrewrk>
yes
<andrewrk>
maybe also the include path
<ky0ko>
i am doing so, include path as well, to no effect
<ky0ko>
with --verbose i can confirm that the compiler is being passed the -I option with the correct path
<ky0ko>
the file exists
<ky0ko>
but Zig claims not to find it
<ky0ko>
scratch that, it probably helps to spell words correctly
<ikskuh>
/opt/hostedtoolcache/zig/zig-linux-x86_64-0.7.0+51d7c14ce/x64/lib/zig/std/debug.zig:1752:1: error: function with calling convention 'C' cannot be async
<ikskuh>
handleSegfaultLinux crashes
<ikskuh>
is this known?
<ifreund>
ikskuh: ah, that's due to lemonboy's recent fix for a deadlock there
<ifreund>
needs a nosuspend I think
<ikskuh>
ah, so we need a fix for the fix :D
jmiven has quit [Quit: reboot]
jmiven has joined #zig
hlolli_ has joined #zig
lucid_0x80 is now known as suskub
suskub is now known as suskun
cren has joined #zig
gpanders has quit [Ping timeout: 264 seconds]
gpanders has joined #zig
gpanders has quit [Ping timeout: 256 seconds]
gpanders has joined #zig
jukan has joined #zig
wootehfoot has joined #zig
jukan has quit [Ping timeout: 256 seconds]
sord937 has quit [Ping timeout: 240 seconds]
sord937 has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
ifreund1 has joined #zig
ifreund2 has joined #zig
ifreund has quit [Disconnected by services]
ifreund2 is now known as ifreund
ifreund1 has quit [Disconnected by services]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
dddddd has joined #zig
Miaourt has quit [Quit: Ping timeout (120 seconds)]
Miaourt has joined #zig
dumenci has joined #zig
suskun has quit [Ping timeout: 240 seconds]
<cren>
if I make an allocation like this: `const memory = try allocator.alloc(u8, 20);`, have I just done something totally pointless? I can read the allocated memory but it consists of random(ish) values, and I can't write it
<novaskell>
You should be able to write as you get slice of `[]u8` back as the slice bound is immutable but the memory it points to isn't
<g-w1>
cren: to assign a string, you want to use mem.copy
<cren>
I was just making the mistake of using double quotes for characters because I come from Python where characters are just strings of length 1
waleee-cl has joined #zig
<cren>
using `allocator.create()`, what is returned is a pointer to a single entity. (object?) If I dereference the pointer and declare a const variable to store the result, I then can't mutate the value, right? Unless I dereference again and create a var
<ifreund>
if you dereference the pointer returned by create and store the result you are making a copy
<ifreund>
you probably just want to store the pointer
jukan has joined #zig
jukan has quit [Client Quit]
hnOsmium0001 has joined #zig
marnix has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
marnix has joined #zig
dumenci has quit [Ping timeout: 260 seconds]
lucid_0x80 has joined #zig
FireFox317 has joined #zig
<ikskuh>
C:\\windows\\system32\\pkg-config.COM
<ikskuh>
what is that?
<ikskuh>
i think i made zig explode :D
<FireFox317>
andrewrk, any opinions on #7271? Should i go for LemonBoys suggestion?
<FireFox317>
Defintely a bug that should be solved before 0.7.1 tho
Akuli has joined #zig
<andrewrk>
FireFox317, I don't understand LemonBoy's comment - your change looks correct to me
<FireFox317>
andrewrk, Well we are just changing the --name paramater, which means we change the output name of the binary. This in theory does not have to rebuild the complete binary, just to change the name
<andrewrk>
ok I think I understand the comment but I still prefer your change
<FireFox317>
Sure :thumbsup:
<andrewrk>
hmm I think I originally planned @import("builtin") to expose that name but looks like that never happened
<andrewrk>
anyway I'd like to merge this
<andrewrk>
sorry for breaking the CI yesterday :-/
<andrewrk>
incoming fix
Snetry has quit [Quit: left Freenode]
<FireFox317>
andrewrk, i dont see why the issue/pr have something to do with @import("builtin"). Am I missing something?
<FireFox317>
Lets say @import("builtin") reflects the name, then it still should be cached right, or is everything in @import("builtin") cached thus no need to add it to the code?
<andrewrk>
if the name was accessible as a comptime value, it would affect the generated zig code
<andrewrk>
my comment was a response to lemonboy
<FireFox317>
ah okay, and thus cause a rebuild.
<FireFox317>
I see
Snetry has joined #zig
<andrewrk>
let me think about it a little bit more real quick
<andrewrk>
FireFox317, ok my argument for keeping your patch as-is: that name is common to all zig source and all C source files because it affects the output path
<FireFox317>
I thought LemonBoy was suggesting that the name of the .o file in the cache directory should reflect the name of the zig source file, and not be affected by the --name parameter i think.
<FireFox317>
Or something like that
<FireFox317>
andrewrk, yep true.
<andrewrk>
I think the logic to name the .o file in the cache directory is correct as is
<andrewrk>
--name changes very rarely. it's ok to have it in the root cache hash
<FireFox317>
:thumbsup:
<andrewrk>
ok, CI should be green now
lucid_0x80 has quit [Quit: Leaving]
mguaypaq has joined #zig
cole-h has joined #zig
mguaypaq has quit [Quit: leaving]
jjsullivan1 has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
jmiven has quit [Quit: bye]
jmiven has joined #zig
GrooveStomp has quit [Ping timeout: 240 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
FireFox317 has quit [Ping timeout: 256 seconds]
FireFox317 has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
FireFox317 has quit [Quit: Leaving]
decentpenguin has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
cren has quit [Quit: cren]
sord937 has quit [Quit: sord937]
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
<mla>
whats a good way to benchmark zig maybe wholesale on a fn-by-fn basis? anything like a sampling profiler like rbspy in zig?
<justin_smith>
mla: with a debug build, I'd expect any standard C profiler to give meaningful results
CodeSpelunker has joined #zig
<justin_smith>
you will probably need to enable libc linkage as well (which shouldn't be a problem for most apps)
radgeRayden has quit [Ping timeout: 272 seconds]
<justin_smith>
a popular choice for linux is gprof
<mla>
justin_smith: thanks for the tip, ill give gprof a whirl
GrooveStomp has joined #zig
<mla>
hmm i need a gmon.out file , wonder if i can have zig generate that
<g-w1>
i know the self-hosted compiler uses tracy, so you could have a look at src/tracy.zig to see how to setup
CodeSpelunker has quit [Quit: CodeSpelunker]
<mla>
i guess for tracy route the whole thing is const tracy = trace(@src()); defer tracy.end(); within the top of each fn
<andrewrk>
zig uses standard debug info as well, so the answer to your question is the same as "what's a good way to benchmark C/C++"
<andrewrk>
I believe the perf function is a sampling profiler
<andrewrk>
s/function/program/
<companion_cube>
there could be python-like decorators? :p
<mla>
thanks, yeah i think im back to gprof, just need to get the right flag to get gmon.out
wootehfoot has quit [Quit: Leaving]
<mla>
oh neat valgrind is working for me good, first time ever profiling at this level but callgrind seems to be working for my usecase
<justin_smith>
mla: gmon.out is a file gprof creates while the program is running (if you've linked gprof)
<justin_smith>
mla: cool - yeah valgrind is a standard option too
marnix has quit [Ping timeout: 256 seconds]
riba has joined #zig
<andrewrk>
alexnask[m], are you around?
Akuli has quit [Quit: Leaving]
<ikskuh>
andrewrk: how stable are f16/half in zig? :D
<andrewrk>
completely
<ikskuh>
wonderful
<ikskuh>
let's do openglfoo with that
<andrewrk>
there are a bunch of targets where we have f16 tests disabled because of LLVM bugs - but they are bugs
<karchnu>
ikskuh: why do you need f16? For computation speed?
ncon has quit [Ping timeout: 260 seconds]
ncon has joined #zig
<justin_smith>
there are gpus that use f16 natively
<andrewrk>
with @setFloatMode(.Strict) zig would have to emulate f16 without target support, but with @setFloatMode(.Optimized) zig would be allowed to use f32 or f64 machine instructions for f16 operations if it decided it was faster
<ikskuh>
<karchnu> ikskuh: why do you need f16? For computation speed?
<ikskuh>
less space
<ikskuh>
texture coordinates for UI rendering
<ikskuh>
i can make my struct 8 or 16 byte large
<andrewrk>
ah I see for in-memory representation
<andrewrk>
yeah just be mindful of your float mode when using f16 in computations
<andrewrk>
I'm guessing for your use case you will actually upcast it to f32 or f64 for computations
<andrewrk>
then downcast to f16 for storage
<ikskuh>
i will never upcast it anyways
<ikskuh>
only downcast precomputed texture coordinates to pass them to the GPU :)
<andrewrk>
I see. Yes I think that should work quite well
<ikskuh>
let's put zig to the test then :)
<ikskuh>
maybe i can show-off something later
riba has quit [Ping timeout: 256 seconds]
g-w1 has quit [Quit: WeeChat 3.1-dev]
g-w1 has joined #zig
<andrewrk>
only 18 issues left in the 0.7.1 milestone...