There is again no context. Do you want support such an old compute facility or just say no we don't support x87? 80 bits is a precise indicator for x87?
Active Repositories
- rZORG LLVM Github Zorg
- Tue, May 30, 1:29 AM
- Git
Recent Activity
Today
Rebase to current llvm-project/main in preparation for merging.
In this case AdjustsStack on line 352 should be initialized to false and MFI.adjustsStack() == AdjustsStack should also be removed making this assertion kind of useless.
If @MatzeB is happy with this, I'm too.
More tests
In D151735#4381703, @tianshilei1992 wrote:IIRC it is CUDA 11.2.
- Added release note.
Fix test on Windows.
Thanks for working on this. Would you mind adding more context to the commit description please?
In D151735#4381683, @jhuber6 wrote:In D151735#4381661, @tianshilei1992 wrote:CUDA's async malloc is really a new thing. It's gonna depend on what version of CUDA we are supporting here.
Do you know which version it was introduced in? It would probably explain why I couldn't built it on the only system I have access to with an Nvidia GPU since it runs CUDA 10.0.
LGTM
In D151735#4381661, @tianshilei1992 wrote:CUDA's async malloc is really a new thing. It's gonna depend on what version of CUDA we are supporting here.
Here is the bug: https://github.com/llvm/llvm-project/issues/63017
I extracted the IR from the JIT test so you don't have to build MLIR (and bugpointed it) :)
clear the line table rows, if the update flag is set, and the line table just has a DW_LNE_end_sequence in DWARFLinker.cpp
CUDA's async malloc is really a new thing. It's gonna depend on what version of CUDA we are supporting here.
ping
Fix typo
Ok, the pre-submission checks failing are actually due to this change. Specifically, parsing the debug_abbrev section of the objects produced by these tests leads to an infinite loop. It goes as follows:
- We fail to get an ULEB128 value for the code because the contents of the debug_abbrev are invalid. The DataExtractor thus returns 0, signaling to the DWARFAbbreviationDeclaration parsing code that were done with this DWARFAbbreviationDeclaration.
- The DWARFAbbreviationDeclarationSet sees it's done and returns an empty Set to the DWARFDebugAbbrev parsing code. The offset is still at 0, so it's still technically a valid offset for the DataExtractor. So we continue on...
LGTM
Thank you, LGTM! Please let me know if you need someone to land this for you.
LGTM
ping