c2go icon indicating copy to clipboard operation
c2go copied to clipboard

unknown node type: "avx512vl"

Open lieff opened this issue 7 years ago • 4 comments

I'm trying to translate https://github.com/lieff/minimp3/blob/master/minimp3_test.c but getting this error:

c2go transpile minimp3_test.c
panic: unknown node type: 'TargetAttr 0x563c6f4606a8 <line:579:74, col:95> "avx512vl"'

goroutine 65 [running]:
github.com/elliotchance/c2go/ast.Parse(0xc424fa0f96, 0x3a, 0x68b37a, 0x5)
        /home/lion/.go/src/github.com/elliotchance/c2go/ast/ast.go:264 +0x424f
main.convertLinesToNodes(0xc420a8bc60, 0x2538, 0x129c7, 0x6c2f302e362d6d76, 0x676e616c632f6269, 0x692f302e302e362f)
        /home/lion/.go/src/github.com/elliotchance/c2go/main.go:89 +0x198
main.convertLinesToNodesParallel.func1.1(0xc420468000, 0xc42000c008, 0xc420a8bc60, 0x2538, 0x129c7, 0x0)
        /home/lion/.go/src/github.com/elliotchance/c2go/main.go:113 +0x59
created by main.convertLinesToNodesParallel.func1
        /home/lion/.go/src/github.com/elliotchance/c2go/main.go:111 +0x112

Hmm, avx? But code uses only sse intrinsic, clang execution problem? Here ast output: ast.txt

lieff avatar Jun 16 '18 22:06 lieff

c2go works by parsing the AST tree output from clang. This is one case where c2go does not know how to deal with the TargetAttr type of node.

This is very easily fixed by creating the node type and a unit test. Here is a recent PR that does exactly that: https://github.com/elliotchance/c2go/pull/770

Let me know if you run into any troubles :)

elliotchance avatar Jun 22 '18 04:06 elliotchance

Thanks for reply :) Ah, I see

|-FunctionDecl 0x5589fa46f218 <line:44:1, line:48:1> line:45:1 _mm_empty 'void (void)' static inline
| |-CompoundStmt 0x5589fa46f468 <line:46:1, line:48:1>
| | `-CallExpr 0x5589fa46f410 <line:47:5, col:25> 'void'
| |   `-ImplicitCastExpr 0x5589fa46f3f8 <col:5> 'void (*)(void)' <BuiltinFnToFnPtr>
| |     `-DeclRefExpr 0x5589fa46f3d0 <col:5> '<builtin fn type>' Function 0x5589fa46f330 '__builtin_ia32_emms' 'void (void)'
| |-TargetAttr 0x5589fa46f2b8 <line:44:71, col:87> "mmx"
| |-NoDebugAttr 0x5589fa46f310 <col:58>
| |-AlwaysInlineAttr 0x5589fa46f320 <col:39> always_inline

This is some kind of function metadata, what instruction sets used. Most of functions marked "mmx", "sse", "f16c", "sse2", "sse3", "ssse3", "sse4.1", "aes", "clflushopt", "clwb", "avx", "avx2", "bmi", "bmi2", "lzcnt", "fma", "avx512f" and "avx512vl" triggers the error. So, we must just skip this node? Or may be just change clang invocation to disable avx* instruction set?

lieff avatar Jun 22 '18 08:06 lieff

First "avx512vl" function is _mm256_mask_add_epi32 from avx512vlintrin.h, included in immintrin.h:

#if !defined(_MSC_VER) || __has_feature(modules) || defined(__AVX512VL__)
#include <avx512vlintrin.h>
#endif

lieff avatar Jun 22 '18 08:06 lieff

There is still only one node type; TargetAttr. The function name (like "mmx" or "avx512vl") would just be a value, so it could be any value. You should only need one unit test to satisfy that panic for all of those cases.

The case where we need more than one unit test for a node is because the syntax of the node itself is different (sometimes parts may be optional).

However, there may be places throughout the code that do not understand what a TargetAttr is and in those cases (if any arise) they should ignore that node type.

Finally, if the functions map to logic that cannot be implemented one way or another in Go it would be best to try and tweak your clang CLI options to produce a "less optimised" version that would be more compatible with the transpiler. That is really its own issue though.

elliotchance avatar Jun 25 '18 05:06 elliotchance