<g-w1>
pog, my pr is also review ready rn. turns out debug.zig has all the color things we need :P
pretty_dumm_guy has joined #zig
Techcable has joined #zig
<andrewrk>
sweet
<g-w1>
i wasn't sure if we should do pretty-printing for c object errors. i didn't do it as the error would be this: test.c:1:1: error: unable to build C object: clang exited with code 1
<g-w1>
compilation probably needs to report it as a compile error better instead of this: error(compilation): clang failed with stderr: test.c:1:10: fatal error: 'test.h' file not found
<andrewrk>
I think I left a bunch of TODO items there to parse clang stderr and turn it into a zig error msg struct
<andrewrk>
then we would report it with proper color and stuff
<andrewrk>
that can be a separate issue
<g-w1>
ok cool
<andrewrk>
the nice thing about that though, when we do it, is that it affects stage1 as well
<g-w1>
i was a little confused, because zig run test.c showed really nice colored errors, but build-exe test.c didn't
<andrewrk>
the answer to that confusion is `clang_passthrough_mode`
<andrewrk>
in this mode zig cc does a "tail call" of the clang process
<g-w1>
zig run calls zig cc if there is only c files?
<andrewrk>
that would not be the case for `zig run` though
<daurnimator>
andrewrk: do you recall my propsal (here in IRC I think) for a `asm else` block that would provide a pure-zig implementation of any assembly block; so that it could be run at comptime?
hiato has quit [Remote host closed the connection]
koakuma has left #zig [#zig]
<andrewrk>
daurnimator, yes
<daurnimator>
andrewrk: I think it would be a neat solution to the discussion re: `__builtin_ia32_packsswb`
<andrewrk>
backend & optimization passes need to be able to reason about these intrinsics
waleee-cl has quit [Quit: Connection closed for inactivity]
bitmapper has quit [Quit: Connection closed for inactivity]
yyp has joined #zig
ur5us_ has quit [Ping timeout: 258 seconds]
andrewrk has left #zig ["Leaving"]
andrewrk has joined #zig
<daurnimator>
andrewrk: can it not reason about it by looking at the assembly and optimizing it (as long as it doesn't have `volatile`)?
<andrewrk>
inline assembly is opaque to optimization and semantic analysis passes
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<daurnimator>
huh? don't you at least need to e.g. do register allocation?
<andrewrk>
most optimization and semantic analysis passes are not aware of registers
fireglow has joined #zig
leon-p has quit [Quit: leaving]
cole-h has joined #zig
sord937 has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
<Anzh>
tm-exa_: well, this becomes memeworthy. Have an issue with something, create a programming language to solve this exact issue. "Safe as x, fast as C!"™
<Anzh>
... Now we have a specialised language for parsing files... Really? >_>
<ugla>
domain-specific languages aren't exactly new
Akuli has joined #zig
<earnestly>
Even printf is one
<earnestly>
As is regex
Anzh has quit [Read error: Connection reset by peer]
Anzh has joined #zig
m4r35n357 has quit [Quit: Ex-Chat]
m4r35n357 has joined #zig
bitmapper has joined #zig
notzmv has quit [Ping timeout: 240 seconds]
<vent>
Although printf, format, regex, etc... are common sub-languages, not an entire language toolchain. Not got anything against DSLs though.
<bndbsh>
andrewrk: thanks for the sample the other day, it helped me narrow things down and make the changes I needed. however, I'm surprised it seems that there are already extern functions in the zig codebase that return small structs (in clang.zig), how come these seem to be working fine?
<bndbsh>
is it just because they only contain ints?
<andrewrk>
the x86_64 C ABI is complicated, and LLVM does not abstract it. worse, LLVM obfuscates what ABI will actually be adhered to, so there end up being a lot of edge cases
<andrewrk>
it's a solvable problem, but it's tricky enough that the priority of fixing it in stage1 has not been elevated high enough to compete with the other pressing matters
<bndbsh>
yeah, I'm discovering just how tricky it is :D. I'm just trying to make sure I'm on the right path, the IR currently generated for small structs in those cases is different from what clang generates, but I guess it happens to lower to compatible asm
<bndbsh>
I'll keep going then, so long as everything builds and runs fine I suppose it's okay to change the IR for the currently working cases?
jzelinskie has joined #zig
<mikdusan>
heh I managed to get netbsd building stage1 on llvm12 branch
<andrewrk>
bndbsh, yeah that's fine, we have great test coverage for that; you'll definitely know if you broke something
<andrewrk>
mikdusan, nice!
<Nypsie>
andrewrk: I'm afraid I can't seem to figure out how to structure the wasm backend differently. Altho the `TextBlock` approach is fine I believe. I keep hitting against the fact that when we do codegen for pointers (.decl_ref) that the target decl hasn't been ran through codegen yet. This means I won't know where that data lives in the 'data' section and can't calculate its offset. Right now, the only
<Nypsie>
possibility I can think of is through patching. But that means we also need to bookkeep references that need to be patched later.
<Nypsie>
If this is too big of a question, I suppose I can try to do it during the stage2 meeting of tomorrow
<andrewrk>
Nypsie, the thing that makes incremental compilation work is that any references to top level declarations (such as functions, but also data) are emitted indirectly, with loads via an offset table. then when that function or top level declaration needs to get moved somewhere else, all we have to do is update the offset table entry for it, and not N modifications to the callsites
<andrewrk>
so the idea would be that you can emit code that does not know what the offset is yet but will load it (at runtime)
<andrewrk>
and in flush() you can write the offset table for all the decls
<andrewrk>
does that make sense?
<ifreund>
Nypsie: I think the approach we use for function calls might work well for pointers as well
<Nypsie>
Ah, so in the wasm binary it will actually call/refer to x (the index into the offset table) rather than the actual value?
<ifreund>
see the place in flush() where the code section is emitted
<andrewrk>
yes that's the idea - so that lets you generate code that is agnostic to the actual virtual address of the function/global
<ifreund>
though yeah, we could also use an offset table in the data section in the emitted binary
<ifreund>
which might be easier
<Nypsie>
ifreund, yeah that's what I ment with the patching. But that means we need to hold references to that pointer similarly to the function calls
<andrewrk>
it's pretty wasteful - you definitely don't want this for release builds - but if you had a large project, this is what makes incremental compilation work
<ifreund>
yeah, thinking about it a bit more we don't *need* the offset table for wasm as we rewrite the file entirely every flush
<ifreund>
however I think it would be easier to implement and more performant
<ifreund>
performant for the compiler, not the generated code
<Nypsie>
andrewrk, I get what you mean now. Thanks a lot!
<Nypsie>
ifreund, keep it in memory instead? And then patch during flush similarly as the call indexes?
<ifreund>
Nypsie: nah, I think we should should emit an offset table into the binary
<ifreund>
then there is only one place that needs to be updated on flush instead of many
<Nypsie>
Gotcha. I think I can do this!
<ifreund>
this means much less bookkeeping and probably faster codegen
<andrewrk>
it's also possible to forget about all this stuff and do everything in flush(). that's not necessarily a horrible idea. you could make the argument that 1. wasm projects are destined to be "small" because they tend to be dowloaded in the browser and 2. this is just incremental linking. even if everything is done on flush() we still benefit from incremental compilation
<andrewrk>
I suggest to try it out, continue down your path to do incremental linking. but we can re-evaluate maybe in a couple weeks in a stage2 meeting if we want to take a different approach
<Nypsie>
Sounds sensible. Let's see where this takes us (the offset table approach) and re-evaluate later then.
<ifreund>
our current path is a happy middle ground I think
<andrewrk>
cool
<Nypsie>
Appreciate the help ifreund, andrewrk. I've been banging my head to my desk today :)
<andrewrk>
you're working on something that as far as I'm aware has not been attempted before, so it makes sense that it would be difficult!
<ifreund>
holding stuff in memory instead of on disk is a massive simplification compared to my first PoC for wasm in-place binary patching
<andrewrk>
I remember that
<Nypsie>
ifreund, it's also a lot easier to visualize (not sure if correct word) it mentally
notzmv has quit [Ping timeout: 260 seconds]
<andrewrk>
"visualize" is exactly the correct word :)
<Nypsie>
Nice :)
<mikdusan>
on my dev system; status: llvm 12.0.0-rc5 is:
<mikdusan>
with tiny patch for #8429 as suggested in upstream,
<mikdusan>
both macos and linux `zig build test` everything passes _EXCEPT_ the big one `zig build test-std` which fails due to the -OReleaseFast #6408 issue
<andrewrk>
damn they tagged rc5 already? we still have 3 open release blockers
<mikdusan>
this is with LLVM enable-asserts
<mikdusan>
rc5 is minor. 1 doc fix and some other thing that doesn't touch us
<mikdusan>
I think it signals they're about to release
sord937 has quit [Quit: sord937]
notzmv has joined #zig
notzmv has quit [Ping timeout: 246 seconds]
Akuli has quit [Quit: Leaving]
<andrewrk>
hope they don't downgrade our release blockers to 12.0.1
ur5us has joined #zig
earnestly has quit [Ping timeout: 265 seconds]
earnestly has joined #zig
teratorn_ has joined #zig
teratorn has quit [Ping timeout: 265 seconds]
notzmv has joined #zig
ur5us has quit [Quit: Leaving]
notzmv has quit [Ping timeout: 260 seconds]
notzmv has joined #zig
trcm has joined #zig
aerona has joined #zig
notzmv has quit [Ping timeout: 260 seconds]
Snetry has quit [Quit: left Freenode]
Snetry has joined #zig
paulgrmn has quit [Ping timeout: 252 seconds]
notzmv has joined #zig
bndbsh has quit [Quit: Connection closed for inactivity]