mewmew
commented
4 years ago @dannypsnl, would you like to take a look at the missing enums? :)
Edit I went ahead and added the enums.
Closed mewmew closed 4 years ago
mewmew
commented
4 years ago @dannypsnl, would you like to take a look at the missing enums? :)
Edit I went ahead and added the enums.
mewmew
commented
4 years ago 39% of the previously failing test cases (279/713) were related to alignment attribute of function definitions.
Fixed in rev d94c2ac4e5403daba2cc8c52da25aca4f78601f4.
2% of the previously failing test cases (15/713) were related to alignment attribute of global declarations.
Fixed in rev d94c2ac4e5403daba2cc8c52da25aca4f78601f4.
3% of the previously failing test cases (23/713) were related to alignment attribute of global declarations.
Fixed in rev a26170572a7b745bbfaf195da89d5790fc1afab3.
0.2% of the previously failing test cases (2/713) were related to metadata.
Fixed in rev a9beaf3778cac7e7cfb19acca7099e8e2aa925ee.
0.2% of the previously failing test cases (2/713) were related to metadata field type.
3% of the previously failing test cases (24/713) were related to null pointer function types.
All test cases previously failed with invalid type of null pointer constant; expected *types.PointerType, got *types.FuncType.
Fixed in rev 9637c11b4d40ce359074707e80e070016e714ec4.
0.8% of previously failing test cases (6/713) were related to missing enums
.
Fixed with rev 3c508edc05be898274a574040d24dccaa181122f.
Fixed by @dannypsnl in #114.
FIxed in rev 31b91b45a51c3ccb511aafd3425822829a03b7c4.
0.4% of currently failing test cases (3/713) are related to constant expression type mismatch.
These test cases fail because they contain invalid LLVM IR. As such, reporting a syntax error is the right thing to do.
7% of previously failing test cases (55/713) are failing on purpose.
Test cases for compatibility with older versions of LLVM IR. We only support the latest version of LLVM IR, as upgrading LLVM IR files to the latest grammar is better handled by the official tools of LLVM (e.g. ll-dis foo.bc)
mewmew
commented
4 years ago To prioritize for the v0.3 release, these test cases have been targeted for a future release of llir/llvm.
0.9% of currently failing test cases (7/713) are related to grammar.
ref: #40.
ref: #43.
ref: #40.
used in call instruction:
llvm/test/Analysis/ValueTracking/memory-dereferenceable.ll
used in return attribute:
llvm/test/Transforms/InstCombine/assume-redundant.ll
llvm/test/Transforms/LoopSimplify/unreachable-loop-pred.ll
Moved to dedicated issue #117.
llvm/test/DebugInfo/unrolled-loop-remainder.ll:attributes #0 = { norecurse nounwind uwtable }
attributes #0 = { norecurse nounwind readnone uwtable }llir/llvm rejects the input and gives the error attribute group ID "#0" already present.
opt accepts the input merges the function attribute definition into:
attributes #0 = { norecurse nounwind readnone uwtable }0.4% of currently failing test cases (3/713) are related to function attribute definitions not being merged.
Moved to dedicated issue #118.
llir/llvm currently rejects llvm/test/CodeGen/X86/extractps.ll as it contains multiple function definitions with the name @"", which causes a name collision.
However, opt accepts this input and treats @"" as unnamed, and assigns global IDs to these unamed global identifiers.
Using opt -S -o a.ll llvm/test/CodeGen/X86/extractps.ll produces:
@0 = external global float
define void @1() { ; <--- given ID 1 from unnamed ""
...
}
define void @2() { ; <--- given ID 2 from unnamed ""
...
}Extract of llvm/test/CodeGen/X86/extractps.ll:
@0 = external global float
define void @""() {
load float, float* @0, align 16
insertelement <4 x float> undef, float %1, i32 0
call <4 x float> @llvm.x86.sse.rsqrt.ss( <4 x float> %2 )
extractelement <4 x float> %3, i32 0
store float %4, float* @0, align 16
ret void
}
define void @""() {
load float, float* @0, align 16
insertelement <4 x float> undef, float %1, i32 1
call <4 x float> @llvm.x86.sse.rsqrt.ss( <4 x float> %2 )
extractelement <4 x float> %3, i32 1
store float %4, float* @0, align 16
ret void
}
declare <4 x float> @llvm.x86.sse.rsqrt.ss(<4 x float>)Only one test case exists which has multiple unnamed global definitions, namely:
@0 = external global float, align 16, new `define internal void @""() nounwind {
dannypsnl
commented
4 years ago For literal 1397723CCABD0000401C666660000000, u0x400000000 and 7FF80000000000000 I created a quick reproduce example:
func main() {
if _, err := strconv.ParseUint("1397723CCABD0000401C666660000000", 16, 64); err != nil {
fmt.Printf("%s\n", err)
}
if _, err := strconv.ParseUint("u0x400000000", 2, 64); err != nil {
fmt.Printf("%s\n", err)
}
if _, err := strconv.ParseUint("7FF80000000000000", 16, 64); err != nil {
fmt.Printf("%s\n", err)
}
}
// Output:
//
// strconv.ParseUint: parsing "1397723CCABD0000401C666660000000": value out of range
// strconv.ParseUint: parsing "u0x400000000": invalid syntax
// strconv.ParseUint: parsing "7FF80000000000000": value out of rangeFor out of range we probably need something like https://github.com/cockroachdb/cockroach/blob/master/pkg/util/uint128/uint128.go
That's the easy part, but for u0x400000000 I can't find document mentions how LLVM integer literal express. Seems like I have to take a look at IR Tokenizer.
mewmew
commented
4 years ago @dannypsnl, thanks for taking a look at this! Here are all the "value out of range" errors I get when parsing all test cases:
Analysis/CostModel/X86/gep.ll
Transforms/InstCombine/fneg.ll
Transforms/SCCP/apint-bigint2.ll
CodeGen/X86/huge-stack-offset2.ll
CodeGen/X86/getelementptr.ll
CodeGen/PowerPC/fast-isel-call.ll
mewmew
commented
4 years ago That's the easy part, but for u0x400000000 I can't find document mentions how LLVM integer literal express. Seems like I have to take a look at IR Tokenizer.
Signed and unsigned hexadecimal integers. Here's another example (from llvm/test/Integer/constexpr_bt.ll):
s0x012312mewmew
commented
4 years ago For literal 1397723CCABD0000401C666660000000, u0x400000000 and 7FF80000000000000 I created a quick reproduce example:
I took a quick look at the test case containing 1397723CCABD0000401C666660000000 (llvm/test/CodeGen/PowerPC/fast-isel-call.ll) and it turns out its a floating-point constant in hexadecimal notation. I'll make sure to update the error message so it doesn't strip the 0x prefix.
As it's a floating-point constant and not an integer constant, this test case would be fixed by #31.
From llvm/test/CodeGen/PowerPC/fast-isel-call.ll:
call void @double_foo(double 0x1397723CCABD0000401C666660000000)Edit: Oh, and it turns out 7FF80000000000000 was also a floating-point constant in hex representation. So both are part of #47
From llvm/test/Transforms/InstCombine/fneg.ll:
%m = fmul <4 x double> %x, <double 42.0, double 0x7FF80000000000000, double 0x7FF0000000000000, double undef>All test cases are now resolved, except for those related to hexadecimal floating-pointer literals. There is a dedicated issue to track progress on adding complete support for hexadecimal floating-point literals, namely #31.
A few test cases are related to module summaries, and a few other aspects of LLVM IR that have been marked for a future release. The dedicated tracking issues are #40, #43, #117 and #118.
As such, we consider this meta issue complete and will it close it for now. Follow-up for future discussions are referred to the issue threads of each dedicated issue.
Currently we have integrated test cases from Coreutils, SQLite and the official LLVM project, and as of #110 we are passing all test cases of implemented language features of LLVM. There are still a few language features left to implement, that were added in LLVM 9.0, and these are tracked by #101, #106, and #43.
To reduce the time needed to run
go testonllir/llvm, we have only enabled a carefully selected subset of the test cases, as there are 20k+ test cases of LLVM.As of rev fba5559079e076debfe70cb2bbb81bf183f28437, if we were to enable all test cases of Coreutils, SQLite and LLVM, we would pass ~96.5% of the test cases (20010/20723 = 96.5%).
As such, this issue tracks the remaining 3.5% of the test cases which are currently failing (713 test cases fail of the total 20723 test cases).
We will start to categorize the failing test cases, and quite likely there are some ~20 language concepts left to implement which will help us pass all test cases of LLVM.
The list of currently failing test cases are as follows.
Not yet resolved (0.2%)
Hexadecimal floating-point literals (0.2% of failing test cases)
0.2% of currently failing test cases (2/713) are related to hexadecimal floating-point literals.
This is tracked by issue #31.
remaining test cases failing
* [llvm/test/CodeGen/PowerPC/fast-isel-call.ll](https://github.com/llir/testdata/blob/68fdb7c8ce371954493b215f547f5261572aadae/llvm/test/CodeGen/PowerPC/fast-isel-call.ll) - strconv.ParseUint: parsing "1397723CCABD0000401C666660000000`value out of range * [llvm/test/Transforms/InstCombine/fneg.ll](https://github.com/llir/testdata/blob/68fdb7c8ce371954493b215f547f5261572aadae/llvm/test/Transforms/InstCombine/fneg.ll) - strconv.ParseUint: parsing "7FF80000000000000`value out of range