LLVM and SPIRV-LLVM-Translator pulldown (WW30 2024) #14813
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- added entrypoints and headerfile parameters depending on target - fixed nits in yaml files causing errors - tested with new cmake config - cmake patch will be seperate
… (#99001) Now turning off/turning on feature is not needed in most cases. This is NFC, tests only.
Fixes 'llvm/CodeGen/GenVT.inc' file not found. Follow up to #98512
…ead of selects (#98774) The previous expansion of [US]CMP was done using two selects and two compares. It produced decent code, but on many platforms it is better to implement [US]CMP nodes by performing the following operation: ``` [us]cmp(x, y) = (x [us]> y) - (x [us]< y) ``` This patch adds this new expansion, as well as a hook in TargetLowering to allow some targets to still use the select-based approach. AArch64 and SystemZ are currently the only targets to prefer the former approach, but other targets may also start to use it if it provides for better codegen.
PR #99056 marked this test case as an XFAIl for ppc64le but it is actually being temporary unsupported, this changes it from an XFAIl to unsupported.
This helps avoid circular dependencies in a follow-up patch.
…:ImportName. NFC. (#98226) On i386, regular C level symbols are given an underscore prefix in the symbols on the object file level. However, the exported names from DLLs usually don't have this leading underscore. When specified in a def file like "symbol == dllname", the "dllname" is the name of the exported symbol from the DLL, which will be linked against from an object file symbol named "_symbol" (on i386). The mechanism where one symbol is redirected to another one in an import library is implemented with weak aliases. In that case, we need to have the object file symbol level name for the target of the import, as we make one object file symbol point at another one. Therefore, we added an underscore to the ImportName field. (This mechanism, with weak aliases, only works as long as the target also is exported as is, in that form - this issue is dealt with in a later commit.) For clarity, for potentially handling the import renaming in other ways, store the ImportName field unprefixed, containing the actual name to import from the DLL. When creating the aliases, add the prefix as needed. This requires passing an extra AddUnderscores parameter to the writeImportLibrary function; this is a temporary measure, until alias creation is reworked in a later commit. This doesn't preserve the corner case of checking !isDecorated() before adding the prefix. This corner case isn't tested by any of our existing tests, and only would trigger for fastcall/vectorcall/MS C++ functions - while these kinds of renames primarily are used in mingw-w64-crt import libraries (which primarily handle cdecl and stdcall functions).
…m64 shared libraries (#98961) We don't currently have a great way to detect the architecture of shared object files under wasm. The currently method involves checking if the imported or exported memory is 64-bit. However some shared libraries don't use linear memory at all. See llvm/llvm-project#98778
…ssible (#98228) This avoids needing to use weak aliases for these cases. (Weak aliases only work if there's another, regular import entry that provide the desired symbol from the DLL.)
…entry (#98229)
Normally, when doing renamed imports, we do this by providing a
weak alias, towards another regular import, for the symbol we
want to actually import. In a def file, this looks like this:
regularfunc
renamedfunc == regularfunc
However, if we want to link against a function in a DLL, where we
(intentionally) don't provide a regular import for that symbol
with the name in its DLL, doing the renamed import with a weak
alias doesn't work, as there's no symbol that the weak alias can
point towards.
We can't make up such an import either, as we may intentionally
not want to provide a regular import for that name.
This situation can either be resolved by using the "long" import
library format (as e.g. produced by GNU dlltool), or by using the
new short import library name type "export as".
This patch implements it by using the "export as" name type.
When producing a renamed import, defer emitting it until all regular
imports have been produced. If the renamed import refers to a
symbol that does exist as a regular import entry, produce a
weak alias, just as before. (This implementation also avoids needing
to know whether the symbol that the alias points towards actually
is prefixed or not, too.)
If the renamed import points at a symbol that isn't otherwise
available (or is available as a renamed symbol itself), generate
an "export as" import entry.
This name type is new, and is normally used in ARM64EC import
libraries, but can also be used for other architectures.
…ng when parsing declaration DIEs. (#98361) This is a reapply of llvm/llvm-project#92328 and llvm/llvm-project#93839. It now passes the [test](llvm/llvm-project@de3f1b6), which crashes with the original reverted changes.
This adds a new document about DXIL Resource Handling. I've attempted to describe here how we intend to use TargetExtTypes to represent resources in LLVM IR and the various intrinsics we'll need to lower these through LLVM to DXIL. For now this document is limited to the high level concepts and a few details on buffer types, and there are a number of TODOs in the document that we'll iterate on as we progress in the implementation.
Updated @B_indices_loaded_in_loop_A_stored to use a different offset for one of the accesses we create runtime checks for; the original version had a runtime check that was always true as the accesses always overlapped.
Summary: The GPU ignores `errno` primarily, but targets want these functions to be defined for certain C standard interfaces. This patch enables them and makes the test function on non-Linux targets.
…#99067) Summary: This patch implements `clock_gettime` using the monotonic clock. This allows users to get time elapsed at nanosecond resolution. This is primarily to facilitate compiling the `chrono` library from `libc++`. For this reason we provide both `CLOCK_MONOTONIC`, which we can implement with the GPU's global fixed-frequency clock, and `CLOCK_REALTIME` which we cannot. The latter is provided just to make people who use this header happy and it will always return failure.
Similar to #98958. The relands 656f617 , which was reverted due to an issue in tsan_platform_mac.cpp Pull Request: llvm/llvm-project#98959
Using single quotes made the build to break on Windows.
This patch adds a test to clang-doc which test the nested namespace generation of clang-doc
This patch adds a test which test the enum generation for clang-doc.
…. (#99070) This matches T-Head documentation and the capitalization we use for the RISCVSubtarget methods.
RISCVInstrInfo already caches a reference to the subtarget object that owns it. We can use that.
This section contains metadata that's only relevant for Identical Code Folding at link time, we should not include it in the output. We still treat it like a regular section during input file parsing (e.g. create a `ConcatInputSection` for it), as we want its relocations to be parsed. But it should not be passed to `addInputSection`, as that's what assigns it to an `OutputSection` and adds it to the `inputSections` vector which specifies the inputs to dead-stripping and relocation scanning. This fixes a "__DATA,__llvm_addrsig, offset 0: fixups overlap" error when using `--icf=safe` alongside `-fixup_chains`. This occurs because all `__llvm_addrsig` sections are 8 bytes large, and the relocations which signify functions whose addresses are taken are all at offset 0. This makes the fix in 5fa24ac ("Category Merger: add support for addrsig references") obsolete, as we no longer try to resolve symbols referenced in `__llvm_addrsig` when writing the output file. When we do iterate its relocations in `markAddrSigSymbols`, we do not try to resolve their addresses.
/llvm-project/mlir/include/mlir/CAPI/Rewrite.h:21:63:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
DEFINE_C_API_PTR_METHODS(MlirRewriterBase, mlir::RewriterBase);
^
1 error generated.
…060) GAS emits warning about newline in the string constant so make the same behaviour.
Conflicts: llvm/lib/SYCLLowerIR/SYCLVirtualFunctionsAnalysis.cpp
|
This is ready for review. Header and API update:
@intel/dpcpp-tools-reviewers Bug fix/workarounds:
Test updates:
@intel/dpcpp-spirv-reviewers XFAIL:
|
|
Ping @intel/dpcpp-cfe-reviewers @intel/dpcpp-spirv-reviewers @intel/dpcpp-tools-reviewers @intel/dpcpp-clang-driver-reviewers |
AlexeySachkov
approved these changes
Aug 7, 2024
There was a problem hiding this comment.
Would be great to have @maksimsab feedback about clang-linker-wrapper changes, but otherwise tools part LGTM
|
@intel/llvm-gatekeepers So, I think this is ready for merge, can someone help to issue a |
|
/merge |
bb-sycl
approved these changes
Aug 8, 2024
|
Thu 08 Aug 2024 07:50:15 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes. |
|
Thu 08 Aug 2024 07:54:39 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM: llvm/llvm-project@09cbb45
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@dad1f0e