-
Notifications
You must be signed in to change notification settings - Fork 787
Sync to LLVM xf672b6170ce #146
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 933 commits into
intel:intel
from
MrSidims:private/MrSidims/Sync_to_LLVM_xf672b6170ce
May 17, 2019
Merged
Sync to LLVM xf672b6170ce #146
vladimirlaz
merged 933 commits into
intel:intel
from
MrSidims:private/MrSidims/Sync_to_LLVM_xf672b6170ce
May 17, 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
llvm-svn: 360533
Pulled out of D58017 while I continue to investigate the BSWAP regression on PPC llvm-svn: 360534
…VectorElts as well. See if we can simplify the demanded vector elts from the extraction before trying to simplify the demanded bits. This helps us with target shuffles and hops in particular. llvm-svn: 360535
Allow using Debian's opt-8, opt-9 with update_test_checks.py Patch by Shawn Landden! Differential Revision: https://reviews.llvm.org/D61148 llvm-svn: 360536
evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. This reinstates r360464 (reverted in r360531) with a workaround for an MSVC bug that previously caused the Windows bots to fail. llvm-svn: 360537
their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. llvm-svn: 360538
Without this, I get e.g. 'PerformPendingInstantiations' -> 'std::fill', now I get 'std::fill<unsigned long *, int>'. Differential Revision: https://reviews.llvm.org/D61822 llvm-svn: 360539
Summary: This check searches for copy assignment operators which might not handle self-assignment properly. There are three patterns of handling a self assignment situation: self check, copy-and-swap or the less common copy-and-move. The new check warns if none of these patterns is found in a user defined implementation. See also: OOP54-CPP. Gracefully handle self-copy assignment https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP54-CPP.+Gracefully+handle+self-copy+assignment Reviewers: JonasToth, alexfh, hokein, aaron.ballman Subscribers: riccibruno, Eugene.Zelenko, mgorny, xazax.hun, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D60507 llvm-svn: 360540
I noticed that we were failing to narrow an x86 ymm math op in a case similar to the 'madd' test diff. That is because a bitcast is sitting between the math and the extract subvector and thwarting our pattern matching for narrowing: t56: v8i32 = add t59, t58 t68: v4i64 = bitcast t56 t73: v2i64 = extract_subvector t68, Constant:i64<2> t96: v4i32 = bitcast t73 There are a few wins and neutral diffs in the other tests. Differential Revision: https://reviews.llvm.org/D61806 llvm-svn: 360541
llvm-svn: 360542
…anded. Removes unnecessary vzeroupper noted in D61806 llvm-svn: 360543
…WithCommonFileID(). llvm-svn: 360544
Summary: The documentation seems to have been manually edited in https://reviews.llvm.org/rGa282bde69e375985edd4c371b79864f617380ad5. This commit regenerates the documentation and commits the resulting diff. Reviewers: benhamilton, mwyman Reviewed By: mwyman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61769 llvm-svn: 360545
Patch by Praveen Velliengiri. Thanks Praveen! https://reviews.llvm.org/D61793 llvm-svn: 360546
Also updates RuntimeDyldChecker and llvm-rtdyld to support zero-fill tests by returning a content address of zero (but no error) for zero-fill atoms, and treating loads from zero as returning zero. llvm-svn: 360547
llvm-svn: 360548
llvm-svn: 360549
For some targets, there is a circular dependency between InstPrinter and MCTargetDesc. Merging them together will fix this. For the other targets, the merging is to maintain consistency so all targets will have the same structure. llvm-svn: 360550
llvm-svn: 360551
…dedBits bitcast handling" I've included a new fix in X86RegisterInfo to prevent PR41619 without reintroducing r359392. We might be able to improve that in the base class implementation of shouldRewriteCopySrc somehow. But this hopefully enables forward progress on SimplifyDemandedBits improvements for now. Original commit message: This patch adds support for BigBitWidth -> SmallBitWidth bitcasts, splitting the DemandedBits/Elts accordingly. The AMDGPU backend needed an extra (srl (and x, c1 << c2), c2) -> (and (srl(x, c2), c1) combine to encourage BFE creation, I investigated putting this in DAGComb but it caused a lot of noise on other targets - some improvements, some regressions. The X86 changes are all definite wins. llvm-svn: 360552
llvm-svn: 360553
llvm-svn: 360554
…g layout. Previously we had only honored alignments on individual atoms, but tools/runtimes may assume that the section alignment is respected too. llvm-svn: 360555
Currently, without -g, BTF sections may still be emitted with data sections, e.g., for linux kernel bpf selftest test_tcp_check_syncookie_kern.c issue discovered by Martin as shown below. -bash-4.4$ bpftool btf dump file test_tcp_check_syncookie_kern.o [1] VAR 'results' type_id=0, linkage=global-alloc [2] VAR '_license' type_id=0, linkage=global-alloc [3] DATASEC 'license' size=0 vlen=1 type_id=2 offset=0 size=4 [4] DATASEC 'maps' size=0 vlen=1 type_id=1 offset=0 size=28 Let disable BTF generation if no debuginfo, which is the original design. Signed-off-by: Yonghong Song <[email protected]> Differential Revision: https://reviews.llvm.org/D61826 llvm-svn: 360556
lli is used by lit/Breakpoint/jitbp_elf.test I had a test failure when running check-lldb-lit because my lli was stale. llvm-svn: 360557
…IBS=on builds after rL360550 This fixes the link error ld.lld: error: undefined symbol: llvm::WebAssembly::anyTypeToString(unsigned int) >>> referenced by WebAssemblyDisassembler.cpp llvm-svn: 360558
evaluation. llvm-svn: 360559
… on an invalid designator. llvm-svn: 360560
llvm-svn: 360561
llvm-svn: 360562
llvm-svn: 360766
This patch adds a simple Cortex-M4 schedule, renaming the existing M3 schedule to M4 and filling in the latencies as-per the Cortex-M4 TRM: https://developer.arm.com/docs/ddi0439/latest Most of these are 1, with the important exception being loads taking 2 cycles. A few others are also higher, but I don't believe they make a large difference. I've repurposed the M3 schedule as the latencies are mostly the same between the two cores, with the M4 having more FP and DSP instructions. We also turn on MISched and UseAA for the cores that now use this. It also adds some schedule Write's to various instruction to make things simpler. Differential Revision: https://reviews.llvm.org/D54142 llvm-svn: 360768
The new cortex-m schedule in rL360768 helps performance, but can increase the amount of high-registers used. This, on average, ends up increasing the codesize by a fair amount (because less instructions are converted from T2 to T1). On cortex-m at -Oz, where we are quite size-paranoid, it is better to use the existing DAG scheduler with the RegPressure scheduling preference (at least until the issues around T2 vs T1 instructions can be improved). I have also made sure that the Sched::RegPressure dag scheduler is always chosen for MinSize. The test shows one case where we increase the number of registers used. Differential Revision: https://reviews.llvm.org/D61882 llvm-svn: 360769
… move This was mentioned both in https://www.viva64.com/en/b/0629/ and by scan-build checks ........ There's concerns this may just introduce a use-after-free instead..... llvm-svn: 360770
Instead of patching the original blocks, we now generate new blocks and delete the old blocks. This results in simpler code with a less twisted control flow (see the change in `entry-block-shuffled.ll`). This will make https://reviews.llvm.org/D60318 simpler by making it more obvious where control flow created and deleted. Reviewers: gchatelet Subscribers: hiraditya, llvm-commits, spatel Tags: #llvm Differential Revision: https://reviews.llvm.org/D61736 llvm-svn: 360771
…convert where needed Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645 Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is now possible, and so can be used to fix the attached bug as well as any cases where SExt instruction results are lost in the debugging metadata. This patch introduces this fix by expanding the salvage debug info method to cover these cases using the new operator. Differential revision: https://reviews.llvm.org/D61184 llvm-svn: 360772
…OP_LLVM_convert where needed" This reverts r360772 due to build issues. Reverted commit: 17dd4d7. llvm-svn: 360773
The implementation should be done by compiler, user can only declare objects of this type and use them in OpenMP directives. Differential Revision: https://reviews.llvm.org/D61860 llvm-svn: 360774
Twine references a StringRef by reference, not value... llvm-svn: 360775
Breaks a bunch of builbdots. llvm-svn: 360776
Differential Revision: https://reviews.llvm.org/D61916 llvm-svn: 360777
Summary: SGPR in CC can be either hw initialized or set by other chained shaders and so this increases the SGPR count availalbe to CC to 105. Change-Id: I3dfadc750fe4a3e2bd07117a2899fd13f3e2fef3 Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61261 llvm-svn: 360778
Implement a check for detecting if/else if/else chains where two or more branches are Type I clones of each other (that is, they contain identical code) and for detecting switch statements where two or more consecutive branches are Type I clones of each other. Patch by Donát Nagy! Differential Revision: https://reviews.llvm.org/D54757 llvm-svn: 360779
Summary: The return value of a TryToUnfoldSelect call was not checked, which led to an incorrectly preserved loop info and some crash. The original crash was reported on https://reviews.llvm.org/D59514. Reviewers: davidxl, amehsan Reviewed By: davidxl Subscribers: fhahn, brzycki, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61920 llvm-svn: 360780
Summary: Change example of input text from being llvm block to being gas block since that text is made-up assembly. Reviewers: jhenderson, jdenny, probinson, arichardson Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61893 llvm-svn: 360781
But don't apply comdat groups when loading the LTO object files. This is basically the same logic used by the ELF linker. Differential Revision: https://reviews.llvm.org/D61924 llvm-svn: 360782
Remove stray space. Signed-off-by: Kevin Petit <[email protected]> llvm-svn: 360783
Removed unconditional and unsafe decrement of counter of active threads in pool at shutdown time. Differential Revision: https://reviews.llvm.org/D61944 llvm-svn: 360784
Summary: modernize-loop-convert was not detecting implicit casts to const_iterator as convertible to range-based loops: std::vector<int> vec{1,2,3,4} for(std::vector<int>::const_iterator i = vec.begin(); i != vec.end(); ++i) { } Thanks to Don Hinton for advice. As well, this change adds a note for this check's applicability to code targeting OpenMP prior to version 5 as this check will continue breaking compilation with `-fopenmp`. Thanks to Roman Lebedev for pointing this out. Fixes PR#35082 Reviewed By: hintonda Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D61827 llvm-svn: 360785
Summary: The emitError path allows the program to continue, unlike report_fatal_error. This is friendlier to use cases where LLVM is embedded in a larger program, because the caller may be able to deal with the error somewhat gracefully. Change the number of requested NOP bytes in the AArch64 and PowerPC test cases to avoid triggering an unrelated assertion. The compilation still fails, as verified by the test. Change-Id: Iafb9ca341002a597b82e59ddc7a1f13c78758e3d Reviewers: arsenm, MatzeB Subscribers: qcolombet, nemanjai, wdng, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61489 llvm-svn: 360786
This reverts r360785 (git commit 42d28be) llvm-svn: 360787
…t iter" with correct attribution Summary: modernize-loop-convert was not detecting implicit casts to const_iterator as convertible to range-based loops: std::vector<int> vec{1,2,3,4} for(std::vector<int>::const_iterator i = vec.begin(); i != vec.end(); ++i) { } Thanks to Don Hinton for advice. As well, this change adds a note for this check's applicability to code targeting OpenMP prior version 5 as this check will continue breaking compilation with `-fopenmp`. Thanks to Roman Lebedev for pointing this out. Fixes PR#35082 Patch by Torbjörn Klatt! Reviewed By: hintonda Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D61827 llvm-svn: 360788
Summary: Analogous to the other ChangeToXXX methods. See the next patch for a use case. Change-Id: I6548d614706834fb9109ab3c8fe915e9c6ece2a7 Reviewers: arsenm, kzhuravl Subscribers: wdng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61651 llvm-svn: 360789
Signed-off-by: Dmitry Sidorov <[email protected]>
vladimirlaz
pushed a commit
that referenced
this pull request
May 8, 2020
CONFLICT (content): Merge conflict in clang/include/clang/Basic/LangOptions.h
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.
Sync to llvm xf672b6170ce
Sync to SPIRV-LLVM-Translator 5e1bbbe37a14