-
Notifications
You must be signed in to change notification settings - Fork 787
LLVM and SPIRV-translator pulldown #815
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
vladimirlaz
merged 934 commits into
intel:sycl
from
vladimirlaz:private/vlazarev/llvm_spirv_pulldown
Nov 12, 2019
Merged
LLVM and SPIRV-translator pulldown #815
vladimirlaz
merged 934 commits into
intel:sycl
from
vladimirlaz:private/vlazarev/llvm_spirv_pulldown
Nov 12, 2019
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
This patch fixes two issues noticed by inspection when going to enable the loop predication code in IndVarSimplify. Issue 1 - Both the LoopPredication transform, and the already on by default optimizeLoopExits transform, modify the exit count of the exits they modify. (either to 0 or Infinity) Looking at the code more closely, this was not reflected into SCEV and we were instead running later transforms with incorrect SCEVs. Fixing this requires forgetting the loop, weakening a too strong assert, and updating SCEV to not pessimize results when a loop is provable untaken. I haven't been able to find a test case to demonstrate the miscompile. Issue 2 - For modules without a data layout, we can end up with unsized pointer typed exit counts. Just bail out of this case. I think these are the last two issues which need addressed before we enable this by default. The code has already survived a decent amount of fuzzing without revealing either of the above. Differential Revision: https://reviews.llvm.org/D69695
This avoids config time dependencies on liblldb. And enables other refactoring.
We had a subtle, but nasty bug in our definition of a widenable branch, and thus in the transforms which used that utility. Specifically, we returned true for any branch which included a widenable condition within it's condition, regardless of whether that widenable condition also had other uses. The problem is that the result of the WC() call is defined to be one particular value. As such, all users must agree as to what that value is. If we widen a branch without also updating *all other users* of the WC in the same way, we have broken the required semantics. Most of the textual diff is updating existing transforms not to leave dead uses hanging around. They're largely NFC as the dead instructions would be immediately deleted by other passes. The reason to make these changes is so that the transforms preserve the widenable branch form. In practice, we don't get bitten by this only because it isn't profitable to CSE WC() calls and the lowering pass from guards uses distinct WC calls per branch. Differential Revision: https://reviews.llvm.org/D69916
Summary: This patch factors out code to clone instructions -- partly for readability and partly to facilitate an upcoming patch of my own. Reviewers: wmi Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69861
Differential Revision: https://reviews.llvm.org/D69805
…nvocations Add support for clangs mangling extension for block invocations. Differential Revision: https://reviews.llvm.org/D69738
To do so, we need to register the sanitizer libraries with the target so that they get uploaded before running. This patch adds a helper to the test class to this effect.
…ng relocs. Some targets (E.g. MachO/arm64) use relocations to fix some CFI record fields in the eh-frame section. When relocations are used the initial (pre-relocation) content of the eh-frame section can no longer be interpreted by following the eh-frame specification. This causes errors in the existing eh-frame parser. This patch moves eh-frame handling into two LinkGraph passes that are run after relocations have been parsed (but before they are applied). The first] pass breaks up blocks in the eh-frame section into per-CFI-record blocks, and the second parses blocks of (potentially multiple) CFI records and adds the appropriate edges to any CFI fields that do not have existing relocations. These passes can be run independently of one another. By handling eh-frame splitting/fixing with LinkGraph passes we can both re-use existing relocations for CFI record fields and avoid applying eh-frame fixups before parsing the section (which would complicate the linker and require extra temporary allocations of working memory).
… means empty set As disscussed in https://reviews.llvm.org/D69918 / https://reviews.llvm.org/D67339 that is an implied postcondition, but it's not really fully tested.
…sat()/uadd_sat() As discussed in https://reviews.llvm.org/D69918 that happens to work as intended, and returns empty set if there is always an overflow because we get lucky with intersection. Since there's now an explicit test for that, let's prefer cleaner code.
Summary: Much like D67339, adds ConstantRange handling for when we know no-wrap behavior of the `sub`. Unlike addWithNoWrap(), we only get lucky re returning empty set for signed wrap. For unsigned, we must perform overflow check manually. A patch that makes use of this in LVI (CVP) to be posted later. Reviewers: nikic, shchenz, efriedma Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69918
The -use-mcjit option was replaced with -jit-kind=mcjit a while back. This patch updates the docs to reflect that. Patch by Yu Jian. Thanks Jian!
…able In the case where xcodebuild fails as you set up simulator tests, you would fail because `feature` is never defined.
Without asan and tsan as test dependencies, you might end up with a clang that points to sanitizer runtime library that hasn't been build yet.
return value location depends on the calling convention of the callee. `F.getCallingConv()`, however, is the caller CC. Correct it to the callee CC from `CallLoweringInfo`. Fixes PR43449 Patch by Shu-Chun Weng!
I'm about to enable the new loop predication transform by default. It has the effect of completely destroying many read only loops - which happen to be a super common idiom in our test cases. So as to preserve test coverage of other transforms, disable the new transform where it would cause sharp test coverage regressions. (This is semantically part of the enabling commit. It's committed separate to ease revert if the actual flag flip gets reverted.)
The basic idea of the transform is to convert variant loop exit conditions into invariant exit conditions by changing the iteration on which the exit is taken when we know that the trip count is unobservable. See the original patch which introduced the code for a more complete explanation. The individual parts of this have been reviewed, the result has been fuzzed, and then further analyzed by hand, but despite all of that, I will not be suprised to see breakage here. If you see problems, please don't hesitate to revert - though please do provide a test case. The most likely class of issues are latent SCEV bugs and without a reduced test case, I'll be essentially stuck on reducing them. (Note: A bunch of tests were opted out of the new transform to preserve coverage. That landed in a previous commit to simplify revert cycles if they turn out to be needed.)
Reflow the CMake properties to take less vertical space. This just makes it easier to read. NFC.
Have CMake treat the unwind libraries as C libraries rather than C++. There is no C++ runtime dependency at runtime. This ensures that we do not accidentally end up with a link against the C++ runtime. We need to explicitly reset the implicitly linked libraries for C++ to ensure that we do not have CMake force the link against the C++ runtime. This adjustment should enable the NetBSD bots to be happy with this change.
This was omitted. Also SReg_96Reg missed IsSGPR assignment. Differential Revision: https://reviews.llvm.org/D69919
…hat require scanning symbols Performance issues lead to the libc++ std::function formatter to be disabled. This change is the first of two changes that should address the performance issues and allow us to enable the formatter again. In some cases we end up scanning the symbol table for the callable wrapped by std::function for those cases we will now cache the results and used the cache in subsequent look-ups. This still leaves a large cost for the initial lookup which will be addressed in the next change. Differential Revision: https://reviews.llvm.org/D67111
"[SLP] Generalization of stores vectorization." "[SLP] Fix -Wunused-variable. NFC" "[SLP] Vectorize jumbled stores." As they're causing significant (10-30x) compile time regressions on vectorizable code. The primary cause of the compile-time regression is f228b53. This reverts commits: f228b53 5503455 21d498c
AMDGPU has some atomic instructions that do not return the previous result, and can only be selected if there are no uses. The source pattern will only match if the use is empty, so it should be safe to discard the result.
This only works if there is no use of the return value.
This reverts commit b5913e6.
…patterns Add pattern matching and intrinsics for the following instructions: predicated orr, eor, and, bic predicated mul, smulh, umulh, sdiv, udiv, sdivr, udivr predicated smax, umax, smin, umin, sabd, uabd mad, msb, mla, mls https://reviews.llvm.org/D69588
and that lldb uses the expedited register values in the ? packet aka stop packet (T11 etc) and does not re-fetch them with the p packet. This test is currently failing from the "[lldb-server] Add setting to force 'g' packet use" commit; I'm marking it as @expectedFailureAll until we can get this fixed.
Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions. Patch by Bharathi Seshadri <[email protected]> Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70014
Adding support for processing the following Decls: NonTypeTemplateParmDecl, CXXConversionDecl, UnresolvedUsingValueDecl, UsingDecl, UsingShadowDecl, TypeAliasTemplateDecl, TypeAliasDecl, VarTemplateDecl, VarTemplateSpecializationDecl, UsingDirectiveDecl, TemplateTemplateParmDecl, ClassTemplatePartialSpecializationDecl, IndirectFieldDecl. Also, this allows for processing NamedDecls that don't have an identifier and skips over VarDecls that are dependent on template types. Differential Revision: https://reviews.llvm.org/D69995
Checking for the exact triple fails on many bots. Leaving the triple check blank.
This reverts commit 2bbc4fd.
until we can automatically fall back to p/P if g/G are not supported; it looks like there is a bug in debugserver's g/G packets taht needs to be fixed, or debugserver should stop supporting g/G until that bug is fixed. But we need lldb to be able to fall back to p/P correctly for that to be a viable workaround.
… parameter. You can't really infer anything from that.
…ession. When bugreporter::trackExpressionValue() is invoked on a DeclRefExpr, it tries to do most of its computations over the node in which this DeclRefExpr is computed, rather than on the error node (or whatever node is stuffed into it). One reason why we can't simply use the error node is that the binding to that variable might have already disappeared from the state by the time the bug is found. In case of the inlined defensive checks visitor, the DeclRefExpr node is in fact sometimes too *early*: the call in which the inlined defensive check has happened might have not been entered yet. Change the visitor to be fine with tracking dead symbols (which it is totally capable of - the collapse point for the symbol is still well-defined), and fire it up directly on the error node. Keep using "LVState" to find out which value should we be tracking, so that there weren't any problems with accidentally loading an ill-formed value from a dead variable. Differential Revision: https://reviews.llvm.org/D67932
Avoid conflict with llvm::remarks::Magic global variable.
Rename option 'Stats' to 'EnableStats' and prevent clash with StatisticInfo::Stats member
- Fix uninitialized variable warnings. - Reuse BitstreamEntry iterator to avoid Wshadow warning. - Match declaration + definition arg names in BitstreamRemarkParser::processCommonMeta - Make BitstreamRemarkParser(StringRef) constructor explicit
Missed Stats->EnableStats rename in rG3fb832fe8bdc317687d5a4d2ca20f5f73b089341
…ning. Patch by Wang Tianqing! Differential Revision: https://reviews.llvm.org/D69792
Before when the overflow occured an assertion was triggered. Now check whether the maximum has been reached and warn properly. This patch fixes the original submission of PR19607. Differential Revision: https://reviews.llvm.org/D63975
This change would have warned about the bug found in D62451. No unit tests since the exception should never throw. Differential Revision: https://reviews.llvm.org/D62452
…v_pulldown Build passed
Signed-off-by: Vladimir Lazarev <[email protected]>
romanovvlad
approved these changes
Nov 12, 2019
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: 27c4eaa
spirv: 4b6b04a3