SPIRV-LLVM-Translator pulldown (WW39) #4612
Merged
Conversation
This file contains hidden or 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
Presently, definitions default to those for Linux which are not defined for FreeBSD (HAVE_LSEEK64, HAVE_MALLINFO, etc.). Patch sets os_defines to posix definitions under FreeBSD. Reviewed By: GMNGeoffrey Differential Revision: https://reviews.llvm.org/D109913
This refactor changes the GlobalMethodPool to a class that contains the DenseMap of methods. This is to allow for the addition of a separate DenseSet in a follow-up diff that will handle method de-duplication when inserting methods into the global method pool. Changes: - the `GlobalMethods` pair becomes `GlobalMethodPool::Lists` - the `GlobalMethodPool` becomes a class containing the `DenseMap` of methods - pass through methods are added to maintain most of the existing code without changing `MethodPool` -> `MethodPool.Methods` everywhere Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D109898
Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D109919
The pattern is returning success even if it does no work leading to pattern application running up to the max iteration count and failing. Reviewed By: nicolasvasilache, mravishankar Differential Revision: https://reviews.llvm.org/D109791
D107799 changed the paths from lib/libcxx(abi)?.a to lib/<triple>/libcxx(abi)?.a. The build script needs to know to pick up the files from the triple subfolder instead. See https://lab.llvm.org/buildbot/#/builders/37/builds/6764 for buildbot log failure. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D109924
…predication To make the IR easier to analyze, this pass makes some minor transformations. After that, even if it doesn't decide to optimize anything, it can't report that it changed nothing and preserved all the analyses. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D109855
Improve checking for NULL() and NULL(MOLD=) when used as variables and expressions outside the few contexts where a disassociated pointer can be valid. There were both inappropriate errors and missing checks. Differential Revision: https://reviews.llvm.org/D109905
Most PDB fields on disk are 32-bit but describe the file in terms of MSF blocks, which are 4 kiB by default. So PDB files can be a bit larger than 4 GiB, and much larger if you create them with a block size > 4 kiB. This is a first (necessary, but by far not not sufficient) step towards supporting such PDB files. Now we don't truncate in-memory file offsets (which are in terms of bytes, not in terms of blocks). No effective behavior change. lld-link will still error out if it were to produce PDBs > 4 GiB. Differential Revision: https://reviews.llvm.org/D109923
When the shapes of actual arguments to ELEMENTAL procedures are sufficiently well known during semantics, require them to conform. Differential Revision: https://reviews.llvm.org/D109909
This patch updates tests added in 5f2b787.
…nager class Finalization and deallocation actions are a key part of the upcoming JITLinkMemoryManager redesign: They generalize the existing finalization and deallocate concepts (basically "copy-and-mprotect", and "munmap") to include support for arbitrary registration and deregistration of parts of JIT linked code. This allows us to register and deregister eh-frames, TLV sections, language metadata, etc. using regular memory management calls with no additional IPC/RPC overhead, which should both improve JIT performance and simplify interactions between ORC and the ORC runtime. The SimpleExecutorMemoryManager class provides executor-side support for memory management operations, including finalization and deallocation actions. This support is being added in advance of the rest of the memory manager redesign as it will simplify the introduction of an EPC based RuntimeDyld::MemoryManager (since eh-frame registration/deregistration will be expressible as actions). The new RuntimeDyld::MemoryManager will in turn allow us to remove older remote allocators that are blocking the rest of the memory manager changes.
…atic-link.cpp We hit some undefined symbol errors to 128-bit floating point functions when linking this test. ld.lld: error: undefined symbol: __multf3 >>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a >>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a >>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a >>> referenced 4 more times >>> did you mean: __muldf3 >>> defined in: /usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a Host libc expects these to be defined, and compiler-rt will only define these for certain platforms (see definition for CRT_LDBL_128BIT). Since we likely can't do anything about the host libc, we can at least restrict the test to check that these functions are supported. Differential Revision: https://reviews.llvm.org/D109709
Complete folding of the intrinsic reduction function COUNT() for all cases, including partial reductions with DIM= arguments. Differential Revision: https://reviews.llvm.org/D109911
…provided When running tests like SanitizerCommon-asan-x86_64-Linux :: Linux/crypt_r.cpp, it may attempt to use the host header crypt.h rather than a sysroot header. This is significant in the event where struct crypt_data defined on host is different from the sysroot used to make the sanitizer runtime libraries. This can result in logical differences between the expected size/layout of struct crypt_data known by sanitizers and the strict crypt_data provided by the host crypt.h. Since tests should still use the CMAKE_SYSROOT, this ensures that CMAKE_SYSROOT is propagated to compiler-rt tests. Differential Revision: https://reviews.llvm.org/D109796
Move the functionality in lld that handles writing of the LC_CODE_SIGNATURE load command and associated data section to a central reusable location. This change is in preparation for another change that modifies llvm-objcopy to reproduce the LC_CODE_SIGNATURE load command and corresponding data section to maintain the validity of signed macho object files passed through llvm-objcopy. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D109803
Add a test to ensure that MachO files including a LC_CODE_SIGNATURE load command produced by lld are signed correctly. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D109840
D105263 adds support for _Float16 type. It introduced a bug (pr51813) that generates a <4 x half> type instead the default double when passing blank structure by SSE registers. Although I doubt it may expose a bug somewhere other than D105263, it's good to avoid return half type when no half type in arguments. Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D109607
Do not call `TryToShrinkGlobalToBoolean` for address spaces that don't allow initializers. It inserts an initializer value while shrinking to bool. Used the target hook introduced with D109337 to skip this call for the restricted address spaces. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D109823
… function Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D109743
Differential Revision: https://reviews.llvm.org/D109349
Added 'this_image()' to the list of functions that are evaluated as intrinsic. Added IsCoarray functions to determine if an expression is a coarray (corank > 1). Added save attribute to coarray variables in test file, this_image.f90. reviewers: klausler, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D108059
Silences a narrowing conversion warning on 32-bit platforms after D109923.
This commit fixes an order-of-initialization issue: If the default mmapper object is destroyed while some global SectionMemoryManager is still using it then calls to the mapper from ~SectionMemoryManager will fail. This issue was causing failures when running the LLVM Kaleidoscope examples on windows. Switching to a ManagedStatic solves the initialization order issue. Patch by Justice Adams. Thanks Justice! Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D107087
This introduces an option to allow specialising on the address of global values. This option is off by default because it is likely not that profitable to do so and needs more investigation. Before, we were specialising on addresses and thus this changes the default behaviour. Differential Revision: https://reviews.llvm.org/D109775
fae0dfa changed code to check 128-bit float availability, since it introduced a new 128-bit double type on PowerPC. However, there're other long float types besides IEEE float128 and PPC double-double requiring this feature. Reviewed By: ronlieb Differential Revision: https://reviews.llvm.org/D109943
This reverts commit 644b55d. The added test is failing the bots.
When adding an image to a target for crashlog purposes, avoid specifying
the architecture of the image.
This has the effect of making SBTarget::AddModule infer the ArchSpec for
the image based on the SBTarget's architecture, which LLDB puts serious
effort into calculating correctly (in TargetList::CreateTargetInternal).
The status quo is that LLDB randomly guesses the ArchSpec for a module
if its architecture is specified, via:
```
SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex
```
... which means that the same crashlog can fail to load on an Apple
Silicon Mac (due to the random guess of arm64e-apple-macosx for the
module's ArchSpec not being compatible with the SBTarget's (correct)
ArchSpec), while loading just fine on an Intel Mac.
I'm not sure how to add a test for this (it doesn't look like there's
test coverage of this path in-tree). It seems like it would be pretty
complicated to regression test: the host LLDB would need to be built for
arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a
binary with an iOS deployment target. I'm open to other / simpler
options.
rdar://82679400
Differential Revision: https://reviews.llvm.org/D110013
…hen splat is in another basic block. NFC We should have CGP copy the splats into the same basic block as the FP operation so that SelectionDAG can fold them.
…for FAdd/FSub/FMul/FDiv.
All supported compilers have supported `=delete` as an extension in C++03 mode for many years at this point. Differential Revision: https://reviews.llvm.org/D109942
This partially reverts commits 1fc2a47 and 9816e72. See D109727. Replacing config.guess in favor of {gcc,clang} -dumpmachine can avoid the riscv64-{redhat,suse}-linux GCC detection. Acked-by: Luís Marques <[email protected]>
This reverts commit 4b80f01. debuginfo-tests has been renamed to cross-project-tests.
CONFLICT (content): Merge conflict in llvm/CMakeLists.txt
CONFLICT (content): Merge conflict in llvm/CMakeLists.txt
Signed-off-by: Dmitry Sidorov <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@a4ac292
… update (intel#1192) DecorationSingleElementVectorINTEl now has one extra operand representing number of pointer stars owned by the element of vector. It helps to restore scalars after translation back. Eg: <i32* x 1>** -> i32*** "VCSingleElementVector"="1" Also it now can be applied to global variables. Original commit: KhronosGroup/SPIRV-LLVM-Translator@4eb63bf
If the return type of an instruction is wider than 64-bit, then this instruction will return via 'sret' argument added into the arguments list. Here we reverse this, removing 'sret' argument and restoring the original return type. TODO: currently 'sret' parameter attribute is being lost during reverse translation for the mentioned case, need to fix it. Original commit: KhronosGroup/SPIRV-LLVM-Translator@a75a62e
Signed-off-by: Dmitry Sidorov <[email protected]>
vladimirlaz
requested review from
AaronBallman,
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
hchilama,
mdtoguchi and
premanandrao
as code owners
|
/summary:run |
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@6cd382b
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@20bcfe88