Lower OpenACCLoopConstruct and most of the clauses to the OpenACC acc.loop operation in MLIR.
This patch refelcts what can be upstream from PR flang-compiler/f18-llvm-project#419
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/tools/lldb-vscode/VSCode.cpp | ||
---|---|---|
41 | Unrelated reformatting? |
lldb/tools/lldb-vscode/VSCode.cpp | ||
---|---|---|
41 | Sure it shouldn't be here. I'll remove it. |
Well I have to see how to add a meaningful unit test here. Lowering unit tests that are currently upstreamed seem to just copy-paste the lowering code which does not really test the lowering code itself.
Yes those are duplicate in a sense, but they are still tests(since nothing else is there) and can self validate well-formedness of the operation(which is one of the major pre-requisite for proceeding further with Lowering).
+ They will ensure matches with community criteria. up-streaming in testable chunks.
I do not have any strong reservations :). Feel free to merge, if you don't like the idea in general :)
Yes those are duplicate in a sense, but they are still tests(since nothing else is there) and can self validate well-formedness of the operation(which is one of the major pre-requisite for proceeding further with Lowering).
+ They will ensure matches with community criteria. up-streaming in testable chunks.
My principal concern is that they do not test the code in genACC or genOMP so they won't catch any problem or regression there. I'm trying to put in place a unit test that make use of the genACC function directly. If that works I'll add the test before landing the patch.
I think that is justified and already tested with full coverage in regression(end-to-end) test with bbc.
I'm trying to put in place a unit test that make use of the genACC function directly. If that works I'll add the test before landing the patch.
+1
The reason why I'm saying this that we(you) also don't want both branches going out-of-sync and regressing further development :)
clang-tidy: warning: invalid case style for function 'GetDesignatorNameIfDataRef' [readability-identifier-naming]
not useful