LLVM and SPIRV-LLVM-Translator pulldown #1329
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
…controller platforms. Summary: The C runner utils API was still not vanilla enough for certain use cases on embedded ARM SDKs, this enables such cases. Adding people more widely for historical Windows related build issues. Differential Revision: https://reviews.llvm.org/D76031
…Test.cpp
offset_t is unsigned, so if the RHS is signed we get a warning from clang:
warning: comparison of integers of different signs: 'const unsigned long long' and 'const int'
Program counter on AIX is the dollar-sign. Differential Revision:https://reviews.llvm.org/D75627
Summary: De-duplicate isel instruction classes by using RRIm for RRINDm. The latter becomes obsolete. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D76063
Summary: On 32-bit PPC target[AIX and BE], when we convert an `i64` to `f32`, a `setcc` operand expansion is needed. The expansion will set the result type of expanded `setcc` operation based on if the subtarget use CRBits or not. If the subtarget does use the CRBits, like AIX and BE, then it will set the result type to `i1`, leading to an inconsistency with original `setcc` result type[i32]. And the reason why it crashed underneath is because we don't set result type of setcc consistent in those two places. This patch fixes this problem by setting original setcc opnode result type also with `getSetCCResultType` interface. Reviewers: sfertile, cebowleratibm, hubert.reinterpretcast, Xiangling_L Reviewed By: sfertile Subscribers: wuzish, nemanjai, hiraditya, kbarton, jsji, shchenz, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75702
…nings. Use castAs as we know the cast should succeed (and castAs will assert if it doesn't) and we're dereferencing it directly in the canAssignObjCInterfaces call.
…nings. Use castAs as we know the cast should succeed (and castAs will assert if it doesn't) and we're dereferencing it directly in the getThisType/getThisObjectType calls.
-M output can be useful when diagnosing an "error: output file too large" problem (emitted in openFile()). I just ran into such a situation where I had to debug an erronerous Linux kernel linker script. It tried to create a file larger than INT64_MAX bytes. This patch could have helped https://bugs.llvm.org/show_bug.cgi?id=44715 as well. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D75966
…t an empty regex
Since D75537 the test suite clears all settings before a test. This caused
two tests to fail:
lldb-api :: functionalities/inline-stepping/TestInlineStepping.py
lldb-api :: lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py
The reason for that is that OptionValueRegex::Clear was setting the regex
to empty instead of the default value that was passed initially. This caused
that the target.process.thread.step-avoid-regexp setting which is used in the
tests was set to "" instead of "^std::".
This patch is just a quick fix that sets the regex back to the original value
to make the tests pass.
In total these 3 setting values have changed with D75537 and also need to be
fixed (even though they don't seem to break any tests).
target.process.thread.step-avoid-regexp (regex) -> from '^std::' to empty string
platform.module-cache-directory (file) -> from "~/.lldb/module_cache" to empty string
script-lang (enum) -> from 'default' to 'python'
…ce warnings. NFCI. All paths dereference the ClassDecl pointer, so use a cast<> instead of dyn_cast<>, assert that its not null and remove the remaining null tests.
This patch is the callee side counterpart for https://reviews.llvm.org/D73209. It removes the fatal error when we pass more formal arguments than available registers. Differential Revision: https://reviews.llvm.org/D74225
Detects and fixes suspicious code like: `#include "foo.cpp"`. Inspired by: https://twitter.com/lefticus/status/1228458240364687360?s=20 https://reviews.llvm.org/D74669
After this change, clang spends ~200ms parsing Attrs.inc instead of ~560ms. A large part of the cost was from the StringSwitch instantiations, but this is a good way to avoid similar problems in the future. Reviewed By: aaron.ballman, rjmccall Differential Revision: https://reviews.llvm.org/D76040
One of the defining features of the SVE ACLE types is that they
are "sizeless"; see the SVE ACLE spec:
https://developer.arm.com/docs/100987/0000/arm-c-language-extensions-for-sve
or the email message:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html
for a fuller definition of what that means.
This patch adds two associated type queries:
- isSizelessBuiltinType asks specifically about types that are built
into clang. It is effectively an enum range check.
- isSizelessType instead tests for any type that has the "sizeless" type
property. At the moment it only returns true for the built-in types,
but it seems better not to hard-code that assumption throughout
the codebase. (E.g. we could in principle support some form of
user-defined sizeless types in future. Even if that seems unlikely
and never actually happens, the possibility at least exists.)
Differential Revision: https://reviews.llvm.org/D75570
…c analyzer warnings. Both these casts are immediately deferenced and the cast will assert for us that they are of the correct type.
This patch adds C and C++ tests for various uses of SVE types.
The tests cover valid uses that are already (correctly) accepted and
invalid uses that are already (correctly) rejected. Later patches
will expand the tests as they fix other cases.[*]
Some of the tests for invalid uses aren't obviously related to
scalable vectors. Part of the reason for having them is to make
sure that the quality of the error message doesn't regress once/if
the types are treated as incomplete types.
[*] These later patches all fix invalid uses that are being incorrectly
accepted. I don't know of any cases in which valid uses are being
incorrectly rejected. In other words, this series is all about
diagnosing invalid code rather than enabling something new.
Differential Revision: https://reviews.llvm.org/D75571
This fixes an issue with clang issuing a warning about unknown CUDA SDK if it's detected during non-CUDA compilation. Differential Revision: https://reviews.llvm.org/D76030
clang current accepts:
void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; }
void foo2(__SVInt8_t *x, __SVInt8_t *y) {
memcpy(y, x, sizeof(__SVInt8_t));
}
The first function is valid ACLE code and generates correct LLVM IR.
However, the second function is invalid ACLE code and generates a
zero-length memcpy. The point of this patch is to reject the use
of sizeof in the second case instead.
There's no similar wrong-code bug for alignof. However, the SVE ACLE
conservatively treats alignof in the same way as sizeof, just as the
C++ standard does for incomplete types. The idea is that layout of
sizeless types is an implementation property and isn't defined at
the language level.
Implementation-wise, the patch adds a new CompleteTypeKind enum
that controls whether RequireCompleteType & friends accept sizeless
built-in types. For now the default is to maintain the status quo
and accept sizeless types. However, the end of the series will flip
the default and remove the Default enum value.
The patch also adds new ...CompleteSized... wrappers that callers can
use if they explicitly want to reject sizeless types. The callers then
use diagnostics that have an extra 0/1 parameter to indicats whether
the type is sizeless or not.
The idea is to have three cases:
1. calls that explicitly reject sizeless types, with a tweaked diagnostic
for the sizeless case
2. calls that explicitly allow sizeless types
3. normal/old-style calls that don't make an explicit choice either way
Once the default is flipped, the 3. calls will conservatively reject
sizeless types, using the same diagnostic as for other incomplete types.
Differential Revision: https://reviews.llvm.org/D75572
A previous patch rejected alignof for sizeless types. This patch extends that to cover the "aligned" attribute and _Alignas. Since sizeless types are not meant to be used for long-term data, cannot be used in aggregates, and cannot have static storage duration, there shouldn't be any need to fiddle with their alignment. Like with alignof, this is a conservative position that can be relaxed in future if it turns out to be too restrictive. Differential Revision: https://reviews.llvm.org/D75573
It would be difficult to guarantee atomicity for sizeless types, so the SVE ACLE makes atomic sizeless types invalid. As it happens, we already rejected them before the patch, but for the wrong reason: error: _Atomic cannot be applied to type 'svint8_t' (aka '__SVInt8_t') which is not trivially copyable The SVE types should be treated as trivially copyable; a later patch fixes that. Differential Revision: https://reviews.llvm.org/D75734
Add YAML traits for the ConstString and FileSpec classes so they can be serialized as part of ProcessInfo. The latter needs to be serializable for the reproducers. Differential revision: https://reviews.llvm.org/D76002
Interface provides uniform access to the the derived attribute query method.
…less type clang accepts a TU containing just: __SVInt8_t x; However, sizeless types are not allowed to have static or thread-local storage duration and trying to code-generate the TU triggers an LLVM fatal error: Globals cannot contain scalable vectors <vscale x 16 x i8>* @x fatal error: error in backend: Broken module found, compilation aborted! This patch adds an associated clang diagnostic. Differential Revision: https://reviews.llvm.org/D75736
Use GraphTraits in the implementation of the GraphDiff's own GraphTraits so GraphDiff can be used across all graph types that provide GraphTraits. Also use partial template specializations to make the traits a bit more compact. Reviewers: asbirlea Differential Revision: https://reviews.llvm.org/D76034
Summary: This improves unwind performance quite substantially, and follows a somewhat similar approach used in libgcc_s as described in the thread here: https://gcc.gnu.org/ml/gcc/2005-02/msg00625.html On certain extremely exception heavy internal tests, the time drops from about 80 minutes to about five minutes. Subscribers: libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D75954
…nterfaces/ Differential Revision: https://reviews.llvm.org/D76155
…esults. Allocate could be used for an "output" of an operation in the case of buffer-style operations.
CONFLICT (content): Merge conflict in clang/include/clang/Basic/Attr.td
Renames the llvm/examples/LLJITExamples directory to llvm/examples/OrcV2Examples since it is becoming a home for all OrcV2 examples, not just LLJIT. See http://llvm.org/PR31103.
…ion state. Inspecting this state can be helpful when debugging jit-linking testcases.
…rivate. Linker-private symbols should be resolvable across object file boundaries.
… tests. NFC Gives us coverage of splitting the v32i16/v64i8 when we have avx512f and not avx512bw. Considering making v32i16/v64i8 a legal type on avx512f which needs this test coverage.
…r than private." This reverts commit b64afad. Reverting while I investigate bot failures.
This is the first in a series of patches to enable Basic Block Sections in LLVM. We introduce a new compiler option, -fbasicblock-sections=, which places every basic block in a unique ELF text section in the object file along with a symbol labeling the basic block. The linker can then order the basic block sections in any arbitrary sequence which when done correctly can encapsulate block layout, function layout and function splitting optimizations. However, there are a couple of challenges to be addressed for this to be feasible: 1) The compiler must not allow any implicit fall-through between any two adjacent basic blocks as they could be reordered at link time to be non-adjacent. In other words, the compiler must make a fall-through between adjacent basic blocks explicit by retaining the direct jump instruction that jumps to the next basic block. These branches can only be removed later by the linker after the blocks have been reordered. 2) All inter-basic block branch targets would now need to be resolved by the linker as they cannot be calculated during compile time. This is done using static relocations which bloats the size of the object files. Further, the compiler tries to use short branch instructions on some ISAs for branch offsets that can be accommodated in one byte. This is not possible with basic block sections as the offset is not determined at compile time, and long branch instructions have to be used everywhere. 3) Each additional section bloats object file sizes by tens of bytes. The number of basic blocks can be potentially very large compared to the size of functions and can bloat object sizes significantly. Option fbasicblock-sections= also takes a file path which can be used to specify a subset of basic blocks that needs unique sections to keep the bloats small. 4) Debug Info and CFI need special handling and will be presented as separate patches. Basic Block Labels With -fbasicblock-sections=labels, or when a basic block is placed in a unique section, it is labelled with a symbol. This allows easy mapping of virtual addresses from PMU profiles back to the corresponding basic blocks. Since the number of basic blocks is large, the labeling bloats the symbol table sizes and the string table sizes significantly. While the binary size does increase, it does not affect performance as the symbol table is not loaded in memory during run-time. The string table size bloat is kept very minimal using a unary naming scheme that uses string suffix compression. The basic blocks for function foo are named "a.BB.foo", "aa.BB.foo", ... This turns out to be very good for string table sizes and the bloat in the string table size for a very large binary is ~8 %. The naming also allows using the --symbol-ordering-file option in LLD to arbitrarily reorder the sections. Differential Revision: https://reviews.llvm.org/D68063
… fixes. Global symbols with linker-private prefixes should be resolvable across object boundaries, but internal symbols with linker-private prefixes should not.
…ump. The extra information can be helpful in diagnosing JIT bugs.
Fixes http://llvm.org/PR44255. Thanks to Raoul Gough for finding the bug!
Summary: This is a simple fix for CodeGenPrepare that freezes branch condition when transforming select to branch. If it is not freezed, instsimplify or the later pipeline can potentially exploit undefined behavior. The diff shows optimized form becase D75859 and D76048 already made a few changes to CodeGenPrepare for optimizing freeze(cmp). Reviewers: jdoerfert, spatel, lebedev.ri, efriedma Reviewed By: lebedev.ri Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76179
Summary: This generates the class declarations for dialects using the existing 'Dialect' tablegen classes. Differential Revision: https://reviews.llvm.org/D76185
CONFLICT (content): Merge conflict in clang/test/Driver/sycl.c
…llvmspirv_pulldown
Added a new decoration DecorationIOPipeStorageINTEL which is attached to a PipeStorage object under a new capability CapabilityIOPipeINTEL. Spec: KhronosGroup/SPIRV-Registry#60 Signed-off-by: Dmitry Sidorov <[email protected]>
Signed-off-by: Dmitry Sidorov <[email protected]>
Added the appropriate checks if the extension is allowed. Signed-off-by: Dmitry Sidorov <[email protected]>
Signed-off-by: Vladimir Lazarev <[email protected]>
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: 429d792
SPIRV-LLVM-Translator: 556ebefa