This seems to be required for ptr_elem_ptr with storage buffers. Note that
this does not imply that the pointer can be regarded as physical too.
Some variants of ptr_elem_ptr will need to be forbidden
This caused a missing reference for u16 to not be emitted. Triggered
after removing something from start.zig which transitively added u16
to the module.
The print order of error sets depends on the order that the compiler
adds names to its internal state. These names can be anything, and
do not necessarily need to be from the same error set or be errors
at all. When the last remaining reference to builtin.cpu.arch was
removed in start.zig in 9b42bc1ce5, this order changed. Likely there
is something that has the name 'C' that is referenced somewhere
recursively from builtin.cpu.arch.
This all causes these few tests to fail, and hence the expected
order is simply updated now. Perhaps there is a better way to
add this.
Under some architecture/operating system combinations it is forbidden
to return a pointer from a merge, as these pointers must point to a
location at compile time. This adds a check for those cases when
returning a pointer from a block merge.
* Use builtin.zig_backend instead of builtin.cpu.arch, the latter
does not yet compile under VK.
* Don't call regular _start for either opencl or vulkan. We might
even want to disable these completely.
This type is exactly the same as std.Build.Cache.Path, except for
one function which is not used anymore. Therefore we can replace
it without consequences.
A compilation build step for which the binary is not required could not
be compiled previously. There were 2 issues that caused this:
- The compiler communicated only the results of the emitted binary and
did not properly communicate the result if the binary was not emitted.
This is fixed by communicating the final hash of the artifact path (the
hash of the corresponding /o/<hash> directory) and communicating this
instead of the entire path. This changes the zig build --listen protocol
to communicate hashes instead of paths, and emit_bin_path is accordingly
renamed to emit_digest.
- There was an error related to the default llvm object path when
CacheUse.Whole was selected. I'm not really sure why this didn't manifest
when the binary is also emitted.
This was fixed by improving the path handling related to flush() and
emitLlvmObject().
In general, this commit also improves some of the path handling throughout
the compiler and standard library.
The old vectorization helper (WipElementWise) was clunky and a bit
annoying to use, and it wasn't really flexible enough.
This introduces a new vectorization helper, which uses Temporary and
Operation types to deduce a Vectorization to perform the operation
in a reasonably efficient manner. It removes the outer loop
required by WipElementWise so that implementations of AIR instructions
are cleaner. This helps with sanity when we start to introduce support
for composite integers.
airShift, convertToDirect, convertToIndirect, and normalize are initially
implemented using this new method.
Previously the child type of a vector was always in indirect representation.
Concretely, this meant that vectors of bools are represented by vectors
of u8.
This was undesirable because it introduced a difference between vectorizable
operations with a scalar bool and a vector of bool. This commit changes the
representation to be the same for vectors and scalars everywhere.
Some issues arised with constructing vectors: it seems the previous temporary-
and-pointer approach does not work properly with vectors of bool. To work around
this, simply use OpCompositeConstruct. This is the proper instruction for this,
but it was previously not used because of a now-solved limitation in the
SPIRV-LLVM-Translator. It was not yet applied to Zig because the Intel OpenCL
CPU runtime does not have a recent enough version of the translator yet, but
to solve that we just switch to testing with POCL instead.
Besides the Intel OpenCL CPU runtime, we can now run the
behavior tests using the Portable Computing Language. This
implementation is open-source, so it will be easier for us
to patch in updated versions of spirv-llvm-translator that
have bug fixes etc.
This allows us to more sanely allocate a continuous
range of result-ids, and avoids a bunch of nasty
casting code in a few places. Its currently not used
very often, but will be useful in the future.
For module parsing and assembling, we will also need to know
all of the SPIR-V extensions and their instructions. This commit
updates the generator to generate those. Because there are
multiple instruction sets that each have a separate list of Opcodes,
no separate enum is generated for these opcodes. Additionally, the
previous mechanism for runtime instruction information, `Opcode`'s
`fn operands()`, has been removed in favor for
`InstructionSet.core.instructions()`.
Any mapping from operand to instruction is to be done at runtime.
Using a runtime populated hashmap should also be more efficient
than the previous mechanism using `stringToEnum`.
Wrapping strange integers before an operation was initially
done as an attempt to minimize the amount of normalizations
required: This way, there would not be a normalization
necessary between two modular operations. This was a
premature optimization, since the resulting logic is more
complicated than naive way of wrapping the result after
the operation.
This commit updates handling of strange integers to do
wrapping after each operation. It also seems slightly
more efficient in terms of size of generated code, as
it reduces the size of the behavior tests binary by
about 1%.
Robin Voetter