Since one of the program header entries is now the program header table
itself, we can avoid tracking it explicitly and just track it as yet
another program segment.
This lets us generate the store with knowledge of the type to be stored.
Therefore, we can avoid generating garbage Air with stores through
pointers to comptime-only types which backends cannot lower.
Closes#13410Closes#15122
Also clean up parsing of linker args - reuse `ArgsIterator`.
In MachO, ensure we add every symbol marked with `-u` as undefined
before proceeding with symbol resolution. Additionally, ensure those
symbols are never garbage collected.
MachO entry_in_dylib test: pass `-u _my_main` when linking executable
so that it is not incorrectly garbage collected by the linker.
In addition, we need to be careful not to mark the relocations as
resolved prematurely as then we are risking malforming the binary
as we need to resolve the relocs twice: once for in-memory writes,
and once for in-file updates.
Ideally, we would just do an atomic rename, but so far I had no
luck. I have also tried marking the file to delete-on-close but
then we cannot use it to spawn the process. So for now, let's just
put a copy in `zig-cache` and let the user decide when to recycle
the cache dir.
* @workItemId returns the index of the work item in a work group for a
dimension.
* @workGroupId returns the index of the work group in the kernel dispatch for a
dimension.
* @workGroupSize returns the size of the work group for a dimension.
These builtins are mainly useful for GPU backends. They are currently only
implemented for the AMDGCN LLVM backend.
As bpf program has no global section for constant values (especially strings),
so use llvm's builtins (like memcpy, memset, etc) will lead to compilation failure
(something like this: A call to built-in function 'memcpy' is not supported.)
Signed-off-by: Tw <tw19881113@gmail.com>
