-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix remaining 0.03% of failing test cases from LLVM test case suite #111
Comments
This comment has been minimized.
This comment has been minimized.
Note: this is not a complete fix, but a pragmatic one, as align is more commonly used for function definitions than return attributes. Anyone well versed with LR-1 grammars, feel free to give hints on how we may resolve this in a proper way. ref: llir/grammar@71126f6. Updates #40. Updates #111.
Resolved (99.9%)Alignment attribute of function definitions (39% of previously failing test cases)39% of the previously failing test cases (279/713) were related to alignment attribute of function definitions. Fixed in rev d94c2ac. test cases failing related to function alignment
Grammar related to Global Alignment Attribute (2% of previously failing test cases)2% of the previously failing test cases (15/713) were related to alignment attribute of global declarations. Fixed in rev d94c2ac. test cases failing related to Global Alignment Attribute grammar
Grammar related to callbr Instruction (3% of previously failing test cases)3% of the previously failing test cases (23/713) were related to alignment attribute of global declarations. Fixed in rev a261705. test cases failing related to callbr Instruction grammar
Grammar related to Metadata (0.2% of previously failing test cases)0.2% of the previously failing test cases (2/713) were related to metadata. Fixed in rev a9beaf3. test cases failing related to Metadata grammarAdditional metadata field type support (0.2% of previously failing test cases)0.2% of the previously failing test cases (2/713) were related to metadata field type. test cases failing related to metadata field type
Null pointer function type (3% of previously failing test cases)3% of the previously failing test cases (24/713) were related to null pointer function types. All test cases previously failed with Fixed in rev 9637c11. test cases failing related to null pointer function types
Missing enum (0.8% of previously failing test cases)0.8% of previously failing test cases (6/713) were related to missing enums test cases failing related to missing enums
Support for negative IDs of local, global and label identifiersFixed with rev 3c508ed.
Support unsigned hexadecimal integer literalsFixed by @dannypsnl in #114.
Address space not computed correctly for indirect symbols (0.4% of failing test cases)FIxed in rev 31b91b4. 0.4% of currently failing test cases (3/713) are related to constant expression type mismatch. test cases failing related to constant expression type mismatch
Broken as intended (7% of previously failing test cases)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. Invalid syntax or semanticstest cases failing on purpose due to invalid syntax or semantics
Require pre-processingtest cases failing on purpose as they require pre-processing
Old grammar compatibility test casesTest 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. test cases failing related to compatibility with an older grammar of LLVM IR
Incorrect .ll extension |
These were related to old enums. ref: llir/llvm#111 (comment)
…Attr, and DebugDirectivesOnly enum of EmissionKind @dannypsnl, I went ahead and added the remaining enums. Updates #111.
…tion type Note, the computed type in the absence of a function signature may be inaccurate since the function may be variadic. Also, fix a bug that has been left unnoticed for quite some time. paramTypes was shadows using `:=` in irCallInst, so the computed speculative function signature would never contain function parameters. Updates #111.
Test cases to fix in a future release (after v0.3)To prioritize for the v0.3 release, these test cases have been targeted for a future release of llir/llvm. Update to grammar needed (0.9% of failing test cases)0.9% of currently failing test cases (7/713) are related to grammar. Grammar related to Function String Attributeref: #40. test cases failing likely related to Function String Attribute grammarGrammar related to Module Summaryref: #43. test cases failing related to Module Summary grammar
align attributeref: #40. used in call instruction:
used in return attribute:
Merge function attribute definitions (0.4% of failing test cases)Moved to dedicated issue #117.
attributes #0 = { norecurse nounwind uwtable }
attributes #0 = { norecurse nounwind readnone uwtable }
attributes #0 = { norecurse nounwind readnone uwtable } 0.4% of currently failing test cases (3/713) are related to function attribute definitions not being merged. test cases failing related to function attribute definitions not being merged
Assign global IDs and support unnamed globals (0.1% of failing test cases)Moved to dedicated issue #118.
However, Using @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:
|
For literal 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 range For 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 |
These were related to identifiers. ref: llir/llvm#111 (comment)
@dannypsnl, thanks for taking a look at this! Here are all the "value out of range" errors I get when parsing all test cases:
|
Signed and unsigned hexadecimal integers. Here's another example (from
|
I took a quick look at the test case containing As it's a floating-point constant and not an integer constant, this test case would be fixed by #31. From call void @double_foo(double 0x1397723CCABD0000401C666660000000) Edit: Oh, and it turns out From llvm/test/Transforms/InstCombine/fneg.ll: %m = fmul <4 x double> %x, <double 42.0, double 0x7FF80000000000000, double 0x7FF0000000000000, double undef> |
With this commit, the following test cases are passing: * llvm/test/Feature/alias2.ll * llvm/test/Assembler/addrspacecast-alias.ll * llvm/test/Transforms/InstCombine/objsize-address-space.ll Updates #111.
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 test
onllir/llvm
, we have only enabled a carefully selected subset of the test cases, as there are 20k+ test cases of LLVM.As of rev fba5559, 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
The text was updated successfully, but these errors were encountered: