The interp package does a much better job at interpretation, and is
implemented as a pass on the IR which makes it much easier to compose.
Also, the implementation works much better as it is based on LLVM IR
instead of Go SSA.
Match data layout of complex numbers to that of Clang, for better
interoperability. This makes alignment of complex numbes the same as the
individual elements (real and imaginary), as is required by the C spec
and implemented in Clang, but unlike the gc compler. The Go language
specification is silent on this matter.
> Each complex type has the same object representation and alignment
> requirements as an array of two elements of the corresponding real
> type (float for float complex, double for double complex, long double
> for long double complex). The first element of the array holds the
> real part, and the second element of the array holds the imaginary
> component.
Source: https://en.cppreference.com/w/c/language/arithmetic_types
The math package uses routines written in Go assembly language which
LLVM/Clang cannot parse. Additionally, not all instruction sets are
supported.
Redirect all math functions written in assembly to their Go equivalent.
This is not the fastest option, but it gets packages requiring math
functions to work.
LLVM supports both "ordered" and "unordered" floating point comparisons.
The difference is that unordered comparisons ignore NaN and produce
incorrect results when presented with a NaN value.
This commit switches these comparisons from ordered to unordered.
* docs: add contributing guidelines to make it easier to help the project
Signed-off-by: Ron Evans <ron@hybridgroup.com>
* docs: add info about Slack channel to contributing guidelines
Signed-off-by: Ron Evans <ron@hybridgroup.com>
There were a few issues that made interp not perform as it should:
* The scan was non-recursive due to a bug.
* Recursive scanning would always return the severity level, which is
not always the best strategy.
The interp package interprets calls in runtime.initAll and replaces
these calls with non-interpretable instructions if needed.
When hitting an unreachable instruction, this call should be removed,
but it wasn't. This commit makes sure the call is removed even before
trying to interpret the package init function.
This commit makes sure all Go types can be encoded in the interface type
code, so that Type.Kind() always returns a proper type kind for any
non-nil interface.
Some instructions emitted by LLVM (like movaps) expect 16-byte
alignment, while the allocator assumed that 8-byte alignment is good
enough.
TODO: this issue came to light with LLVM optimizing a complex128 store
to the movaps instruction, which must be aligned. It looks like this
means that the <2 x double> IR type is actually 16-byte aligned instead
of 8-byte like a double. If this is the case, the alignment of complex
numbers needs to be updated in the whole compiler.
Ayke van Laethem
Ron Evans
Daniel Esteban
admin