- User Since
- Dec 7 2016, 2:42 PM (162 w, 4 d)
Fri, Jan 17
Addressed review comments.
Thu, Jan 16
Wed, Jan 15
Rebased and addressed review comments.
Sat, Jan 4
Fri, Jan 3
Addressed review comment.
Thu, Jan 2
Nov 22 2019
Wrapper tool is invoked at link phase, therefore there just could be no .bc files available to read data layout from. Ok, looks like there is no good solution for the data layout problem, so I will drop the idea of passing wrapper .bc directly to the linker when LTO is enabled (at least for now:). I will abandon this patch.
I would agree with you if data layout was indeed available in the driver, but unfortunately driver does not have access to any existing TargetInfo instance (or maybe I just have not found it). So, I have to create TargetInfo and build data layout even for the case when driver passes it to the wrapper tool. I guess that would also be a default data layout, so it would not differ much from what I have already done in this patch. BTW, I will probably upload an alternative patch where I have implemented your suggestion, just to compare))
Ok, it is possible to do it like you suggested, but I think that teaching wrapper tool to set data layout without external help is more preferable. There is a certain difference between opt and wrapper tool – opt works on the existing .bc that is provided in command line and data-layout option just gives user an optional way to override input’s data layout while wrapper tool creates output .bc from scratch. With your proposal, data-layout would become sort of mandatory option for the wrapper tool which is not very convenient. I believe wrapper tool should be able to set it without external help, and we can always add an option to override data layout (similar to opt) if there would be a need for that.
Nov 21 2019
Nov 15 2019
Nov 14 2019
Addressed review comments.
I think using generated object in the test is more preferable since yaml definition can be adjust if there would be a need for that, but it turned out that yaml2obj tool also has problems with COFF’s extended relocation tables. I have prepared a patch to fix this problem in the yaml2obj – D70251
Nov 13 2019
Added real object with extended relocations for LIT test.
Nov 5 2019
Oct 25 2019
Oct 22 2019
Oct 17 2019
Oct 16 2019
All three parts have been committed, so I am abandoning the original patch.
Oct 15 2019
Oct 13 2019
Oct 11 2019
Rebased patch and addressed review comments.
Oct 10 2019
Oct 9 2019
I have uploaded the last part to https://reviews.llvm.org/D68746
Oct 4 2019
Rebased patch and changed clang-offload-wrapper CMakeLists.txt to use add_clang_tool() rather than add_clang_executable() with a custom install rule.
Oct 2 2019
Addressed some comments and rebased patch.
Sep 27 2019
The second part was uploaded to https://reviews.llvm.org/D68166.
Sep 26 2019
I have uploaded the first part to https://reviews.llvm.org/D68070
Sep 25 2019
This patch is no longer relevant since it was agreed to split https://reviews.llvm.org/D64943 into pieces in a different way.
I have rebased patch and addressed last Alexey’s comments. If there are no more comments, I propose to split this patch into 3 pieces
Sep 18 2019
Sep 12 2019
- Changed offload entry section name to “omp_offloading_entries”
- Wrapper bit-code now uses start_ omp_offloading_entries/stop_ omp_offloading_entries symbols for accessing offload entry table assuming that these symbols are defined by the linker
- Removed omptargetbegin.o/omptargetend.o objects
Sep 11 2019