Metalibm's vectorizer crashes when trying to generate a vector function with --sub-vector-size=1

When metalibm vectorizes a function it duplicates the coefficient tables:

• once for scalar callback
• once for each sub-vector split

It seems some of metalibm's modules are relaying on non-deterministic structure (e.g. python dict) which in some cases can have random process orders which change between execution (for example the SymbolTable table seems to suffer from this symptom).

To help debug and reproducibility it seems key to ensure than consecutive generations in the same conditions provides exactly the same outputs.

CopySign operations class seems to expect two arguments (based on abstract_type_rule implementation) but GenericProcessor implements discards the second argument and does not take it into account.

Currently Metalibm's format equality is only partially implemented
Several isomorphic type can be declared separately and should return true when compared for equality
(example fixed_point(3,0) == fixed_point(3, 0) in HDL formats)

Several meta-functions exist to generate a cosine: ml_cos and ml_sincos

ml_sincos is the most recent one but ml_cos provided gappa partial certificate for the argument reduction. The two should be merged together into a single meta-function and the other one cleared out of the repository.

in python 3

    print "building mathematical polynomial"
                                           ^
SyntaxError: Missing parentheses in call to 'print'

in python 2:

TBD

Comparisons of core.special_values such as signed infinities return erroneous results
when compared with numerical values:

from metalibm_core.core.special_values import FP_MinusInfty
from metalibm_core.core.ml_formats import ML_Binary32

print(FP_MinusInfty(ML_Binary32) > 0)

Most implementations associated with TableStore and TableLoad in most backend do not verify the table's storage format before determining the implementation.
The default behaviour is that a TableOperation will address the table based on the table's storage format and operation index(es) (and not the operation non-table source / destination)

was copied from gitlab (issue #10)

Currently many transforms / legalization do not forward attributes from the source to the transform result which means a lot of information may be lost in the process.

suggest a mechanism to forward the attributes from source to destinatio
Document the mechanism
Implement the mechanism
Test the mechanism

@mistoan discovered the following issue with ml_exp and llvm target:

python3 metalibm_functions/ml_exp.py --target llvm --language ll --passes beforecodegen:gen_basic_block,beforecodegen:ssa_translation --exit-on-error
Error: basic block BasicBlock[None] -------> bb_28
 is empty and does not have a last op

copied from gitlab (Issue #8)

There are several meta-operations around negation with fuzzy specification and legacy implementation. They should be clean-up, documented and validated

Current meta implementation of fmod is only a dummy implementation, accurate only if x and y are not too far apart.
It should be refined into a proper implementation working for the full range of inputs.

For example the following test fails in single precision:
ml_fmod(0x1p+100, 0x1.4e4p-10), result is -0x1.17p+75 vs expected [0x1.3cp-12;0x1.3cp-12]

Extend valid.soft_coverage_test to display throughput information for each generated function (clock per element)

FP_PlusOmega and FP_MinusOmega special values defined in core.special_values are not really special values, the classes should be removed and replaced by functions which generate the correct numerical value from the precision argument without forcing metalibm to implement complex logic to manage this aliased value.

table objects such as ML_Table / ML_NewTable instances are not generated as constant / unmutable objects in source code (e.g. in C source code).
Most of those tables, especially the ones uses during approximation are only read from and the performance could benefit from declaring those object as const / read-only in source code.

Some function implementation (e.g. current meta tanh) requires a lot of polynomial approximations.
Those approximations are often used in multiple variants (scalar, v2, v4, f8). Currently they have to be found / verified each time.
An interesting feature could be to allow saving/loading polynomial coefficient from an external file.
With the proper predicate / verification, this feature would speed up some generations a lot.

e.g precision=binary32, target=generic, input=0x1.fca482p-1
generic_log should generate a faithful implementation

Metalibm only supports half precision (binary16 / ML_Binary16) formats for RTL generation.
No software support is currently presents, thus no meta function can be generated to target binary16 formats

Possible solutions:

• extend targets with binary16 mapping (for targets which support it)
• support binary16 through conversion to / from binary32 and internal implementation on binary32 tuned for binary16 accuracy and exponent range
• other

Each metalibm module can define it own verbosity level.
It would be interesting to have a command-line option to list all the level available.

In meta-function, ExponentExtraction provided the number exponent (similar to ceil(log2(abs))) wheras in meta-entity ExponentExtraction returns the biased exponent.

python3 metalibm_hw_blocks/mult_array.py --mult-desc "FU2.0xFU2.0" --precision FU6.0

generate source code with the following invalid constructs:

    ftmp3 <= opu_0(0);
    (...)
    ftmp3 <= ftmp2;

where

    opu_0(0) <= ftmp2;

was expected:

In python3 the generation expands the left-hand side expression to a CodeVariable where it should remain an expression.
The issue does not seem to appear in python2

It seems optimization passes are imported multiple times while building documentation with sphinx, which leads to sphinx crashing because Metalibm used to prevent multiple pass import.

to reveal:

• revert kalray@9a13ec5
• build sphinx doc (./doc/generate_doc.sh)

When factorizing a sub-expression between several branches subexpr_sharing should take into account that an experssion value may be modified for a branch by a ReferenceAssign on one of the Variable used in the expression (directly or indirectly) and not go forward with the factorization.

Clean-up Floating-Point comparison specifier (copied from gitlab, was Issue #19)

Following discussion with @hdelassus : And looking at https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=720&text=_mm256_cmp_ps&techs=AVX we need to clarify the specification of Metalibm Comparison specifier so they can match more closely the predicates defined by the standard for floating-point arithmetic (including Ordered / Unordered, Quiet / Signaling behaviors)

Actions:

Review current Specifier specification
Suggest evolution / extension
Implement change + Add unit-testing and validate non-regression

copied from gitlab (was Issue #13)

@hdelassus mentionned in an email that he has some difficulties debugging the code generation when ComplexOperator are involved: the operation graph is modified at the last minute before codegen and sometimes unsupported sub-graph are inserted without the ability to determine their origin when they failed to match an implementation in the backend. This looks like a recurrent problem, encountered very often that we need to address, feel free to suggest solution in this issue: They are a few possibilities I can already think of:

move ComplexOperator legalization to a legalization pass which allows to insert a "dump" pass before codegen and evaluate graph coherency beforehand
force ComplexOperator and other legalization transformation to tag the newly inserted nodes so that we can infer their origin from their tag (difficulty: combining user-defined tags and transformation-defined tags)
add an extra attributes to each node which may link them to the transformation that inserted the node or modified it

To be discussed ...

When building a ML_Table the table elements are often rounded before being inserted into the table.
When source code is generated for the table, the same constants are also rounded when get_cst is called.
This multiple rounding is inefficient (it should not lead to double-rounding as target precision is identical)

Raise and RaiseReturn specification is ill-defined
They are the only operations using extra_inputs
RaiseReturn could be aliased to Statement(Raise, Return)

I have followed these steps.

$ git clone https://github.com/kalray/metalibm.git metalibm-lugdunum
$ git reset --hard origin/master

$ virtualenv -p /usr/bin/python3 .venv3
$ source .venv3/bin/activate
$  pip install git+https://gitlab.com/metalibm-dev/pythonsollya

$ PYTHONPATH=${PYTHONPATH}:`pwd` python3 metalibm_functions/ml_exp.py --precision binary32 --target x86_avx2 --output x86_avx2_exp2d.c

Traceback (most recent call last):
  File "metalibm_functions/ml_exp.py", line 30, in <module>
    import sollya
ImportError: /home/pmallapp/tmp/metalibm-lugdunum/.venv3/lib/python3.7/site-packages/sollya.cpython-37m-x86_64-linux-gnu.so: undefined symbol: sollya_lib_obj_is_externaldata

When initializing a target metalibm recreate a list of the target parents and generate their local_op_map. If a targets has a lot of parents each time, one of them is initialized it will recreate the full list of instances of its own parent (which may be the same as the top target) with no instance sharing.

This occurs for example when listing the software unit tests:

python3 -m cProfile -o sut.prof ./valid/soft_unit_test.py --list

the meta operation RawSignExpExtraction is not clearly defined and its implementation in ml_support_lib/ml_utils.h does not provide a lot of clue with respect to its intended behaviour.

reset and recirculate signals in RTL are not handled correctly when generated a HDL testbench

• if reset name differs from "reset" it may be considered as a standard input and stimuli may be generated for it
• recirculate signals are also not handled properly and not assigned a valid value during a testbench

Currently, to add a new command line argument to a meta-function, two modifications are required:

• adding a new argument to the command line parser (argparse) in main section
• declaring the new argument and a default value in the structure used in the meta-function get_default_args method to build default argument values.
  Only one modification should be required with a unified default argument structure used to generate the command line interface

Issue report by @hdelassus from metalibmwebapp

When the expression "sin(x)" is generated from function_expr, the type passes goes through a ReferenceAssign node (due to the indirection created by function_expr) which change the default_precision from None (as instanciated by default when the pass PassInstanciateAbstractPrecision is instanciated in the default GenericProcessor pipeline) to ReferenceAssign's precision / var_type which lead to a bad resolution of operation format.

python3 ../metalibm_functions/function_expr.py "sin(x)"

Compilers support for generic vector types (e.g. GCC's vector extensions https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html) has greatly improved in the recent years. Metalibm vector backend still defines its own, inefficient, vector types and vector operations.

It would be a good idea to deprecate the current vector support library (support_lib/ml_vector_lib.h) and to develop a new version of the vector backend relying on "standard" C vector types (based on types defined with __attribute__((vector_size()))) and also relying on vector operations supported by the compilers.

When an auto-test wapper is generated, if the tested implementation returns a NaN while a number is expected then the comparison (at least for faithful accuracy) fails to detect that the result does not match the expected value (as faithful predicates checks that NaN < low or NaN > value is false, which is always the case in C for a number value).

Add support for Google's brain float16 format: https://cloud.google.com/tpu/docs/bfloat16

Following discussion with grevy It should be possible to:

• define pointer function format object
• declare variable and input variable of those objects
• being able to call variable function with specified parameters

ml_special_value.h header should be replaced by a proper inline generation of special value constant.
This would reduced the number of specific include required in most generated file.

https://github.com/kalray/metalibm/blob/master/metalibm_core/support_lib/ml_special_values.h

copied from gitlab (was Issue #5)

Metalibm's OpenCL backend support a shift on floating-point inputs and outputs without clear specifications (does it implictly cast the input to / and output from signed or unsigned integer values when shifting). This instruction selection should be removed.

Currently constant code generation is embedded into constant classes, and this for various target langague. format's get_cst, get_c_cst and get_vhdl_cst methods generates the requested code.

This architecture is difficult to extend as it requires modifying metalibm core ml_formats module to add support for other languages. As Constant are now supported in standard in backend description, it could be a good idea to re-implement ConstantOperator without relying on formats methods directly but rather implementing backend specific function for constant generation.

was copied from gitlab (Issue #11)

Virtual and Fixed formats have seen a lot of circular dependency and back & forward base_format / support_format definition lately. They require proper specification, cleaning and testing

metalibm uses temporary files for various tasks:

• gappa file are generated during error evaluation
• binary file are generated during build
• ...
  Currently there is no way to indicate where those files should be created, or if they should be destroyed after use.

Specify a format to specify tests for the valid.soft_coverage utlity

in python3

 python3 metalibm_functions/ml_sin.py
  File "metalibm_functions/ml_sin.py", line 111
    print "generating polynomial evaluation scheme"
                                                  ^
SyntaxError: Missing parentheses in call to 'print'