-
Notifications
You must be signed in to change notification settings - Fork 768
LLVM and SPIRV translator pulldown #758
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 1,583 commits into
intel:sycl
from
vladimirlaz:private/vlazarev/pulldown_llvmdc1499b9_spirve7a8ed81
Oct 28, 2019
Merged
LLVM and SPIRV translator pulldown #758
vladimirlaz
merged 1,583 commits into
intel:sycl
from
vladimirlaz:private/vlazarev/pulldown_llvmdc1499b9_spirve7a8ed81
Oct 28, 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
Summary: Also changes the wasm YAML format to reflect the possibility of having multiple return types and to put the returns after the params for consistency with the binary encoding. Reviewers: aheejin, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69156 llvm-svn: 375283
llvm-svn: 375284
llvm-svn: 375285
…e test. They're not stable across machines. Fixes buildbots after r375278. llvm-svn: 375286
Previously, the parser checked for a '%' prefix to indicate a register. In Intel syntax mode, LLVM does not print a '%' prefix on registers, so LLVM could not parse its own assembly output. Instead, require that register numbers be integer literals, or at least start with an integer literal, which is consistent with .cfi_* directive register parsing. llvm-svn: 375287
Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
llvm-svn: 375289
This is really embarrassing. Those are pointers, so that offsets the pointers, not the statistics pointed-by the pointer... llvm-svn: 375290
Provide a little more detail for the reproducer command. llvm-svn: 375292
Summary: The implementation was never completed and never used except in tests. Reviewers: arsenm, mareko Subscribers: qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69163 llvm-svn: 375293
I'm having a hard time reproducing this and it's failing on the Windows bot. Temporarily X-failing this test while I continue to try building LLDB on Windows. llvm-svn: 375294
…ng used by ExtBinary format profile Profile on-demand loading was added for ExtBinary format profile in rL374233, but currently profile on-demand loading doesn't work well with profile remapping. The patch adds the support. Suppose a function in the current module has outline instance in the profile. The function name in the module is different from the name of the outline instance, but remapper knows the two names are equal. When loading profile on-demand, the outline instance has to be loaded with remapper's help. At the same time SampleProfileReaderItaniumRemapper is changed from a proxy of SampleProfileReader to a helper member in SampleProfileReader. Differential Revision: https://reviews.llvm.org/D68901 llvm-svn: 375295
Summary: This has been an experiment with late malloc interposition, made possible by a non-standard feature of the Android dynamic loader. Reviewers: pcc, mmalcomson Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69199 llvm-svn: 375296
If all uses of a PHI are in AGPR register class we should avoid unneeded copies via VGPRs. Differential Revision: https://reviews.llvm.org/D69200 llvm-svn: 375297
…lity_wrapper. Differential Revision: https://reviews.llvm.org/D69201 llvm-svn: 375298
This matches the CMake build. Differential Revision: https://reviews.llvm.org/D69202 llvm-svn: 375299
If a subregister def was moved across another subregister def and another use, the main range was not correctly updated. The end point of the moved interval ended too early and missed the use from theh other lanes in the subreg def. llvm-svn: 375300
When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 llvm-svn: 375301
…on, even when nested in another class template specialization Differential Revision: https://reviews.llvm.org/D63031 llvm-svn: 375304
operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
…is_invocable that would internally conjure up a deprecated function type. Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings. Reviewers: mclow.lists, EricWF Subscribers: christof, ldionne, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68879 llvm-svn: 375307
Makes life easier for downstream developers with different default standard. llvm-svn: 375308
Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
Reviewers: tra, sfantao, echristo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69124 llvm-svn: 375310
MachineInstr.h included AliasAnalysis.h, which includes a world of IR constructs mostly unneeded in CodeGen. Prune it. Same for DebugInfoMetadata.h. Noticed with -ftime-trace. llvm-svn: 375311
This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
The Windows bots are failing with: clang: warning: argument unused during compilation: '-dynamiclib' [-Wunused-command-line-argument] llvm-svn: 375315
Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
- Reduce code duplication - Get partial support of JAL expansion for XGOT.
Testing git commit access.
Member operator declarations and member operator expressions have different numbering of parameters and arguments respectively: one of them includes "this", the other does not. Account for this inconsistency when figuring out whether the parameter needs to be manually rebound from the Environment to the Store when entering a stack frame of an operator call, as opposed to being constructed with a constructor and as such already having the necessary Store bindings. Differential Revision: https://reviews.llvm.org/D69155
…flags from `add` op Summary: This was suggested in https://reviews.llvm.org/D69277#1717210 In this form (this is what was suggested, right?), the results aren't staggering (especially since given LVI cross-block focus) this does catch some things (as per test-suite), but not too much: | statistic | old | new | delta | % change | | correlated-value-propagation.NumAddNSW | 4981 | 4982 | 1 | 0.0201% | | correlated-value-propagation.NumAddNW | 12125 | 12126 | 1 | 0.0082% | | correlated-value-propagation.NumCmps | 1199 | 1202 | 3 | 0.2502% | | correlated-value-propagation.NumDeadCases | 112 | 111 | -1 | -0.8929% | | correlated-value-propagation.NumMulNSW | 275 | 278 | 3 | 1.0909% | | correlated-value-propagation.NumMulNUW | 1323 | 1326 | 3 | 0.2268% | | correlated-value-propagation.NumMulNW | 1598 | 1604 | 6 | 0.3755% | | correlated-value-propagation.NumNSW | 7158 | 7167 | 9 | 0.1257% | | correlated-value-propagation.NumNUW | 13304 | 13310 | 6 | 0.0451% | | correlated-value-propagation.NumNW | 20462 | 20477 | 15 | 0.0733% | | correlated-value-propagation.NumOverflows | 4 | 7 | 3 | 75.0000% | | correlated-value-propagation.NumPhis | 15366 | 15381 | 15 | 0.0976% | | correlated-value-propagation.NumSExt | 6273 | 6277 | 4 | 0.0638% | | correlated-value-propagation.NumShlNSW | 1172 | 1171 | -1 | -0.0853% | | correlated-value-propagation.NumShlNUW | 2793 | 2794 | 1 | 0.0358% | | correlated-value-propagation.NumSubNSW | 730 | 736 | 6 | 0.8219% | | correlated-value-propagation.NumSubNUW | 2044 | 2046 | 2 | 0.0978% | | correlated-value-propagation.NumSubNW | 2774 | 2782 | 8 | 0.2884% | | instcount.NumAddInst | 277586 | 277569 | -17 | -0.0061% | | instcount.NumAndInst | 66056 | 66054 | -2 | -0.0030% | | instcount.NumBrInst | 709147 | 709146 | -1 | -0.0001% | | instcount.NumCallInst | 528579 | 528576 | -3 | -0.0006% | | instcount.NumExtractValueInst | 18307 | 18301 | -6 | -0.0328% | | instcount.NumOrInst | 102660 | 102665 | 5 | 0.0049% | | instcount.NumPHIInst | 318008 | 318007 | -1 | -0.0003% | | instcount.NumSelectInst | 46373 | 46370 | -3 | -0.0065% | | instcount.NumSExtInst | 79496 | 79488 | -8 | -0.0101% | | instcount.NumShlInst | 40654 | 40657 | 3 | 0.0074% | | instcount.NumTruncInst | 62251 | 62249 | -2 | -0.0032% | | instcount.NumZExtInst | 68211 | 68221 | 10 | 0.0147% | | instcount.TotalBlocks | 843910 | 843909 | -1 | -0.0001% | | instcount.TotalInsts | 7387448 | 7387423 | -25 | -0.0003% | Reviewers: nikic, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69321
…ockValueIntrinsic() Now that there's SaturatingInst class, this is cleaner.
Summary: This is a fix to revision D68839 and rL375023. This patch substitutes POSIX option "-b" for the non-portable GNU option "--strip-trailing-cr". Reviewers: daltenty, hubert.reinterpretcast Reviewed By: daltenty Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69342
I should have updated it in 1f66504 but i didn't even realize those tests were there.
Summary: A certain class of bug (e.g. infloop on an AST worker thread) currently means clangd never terminates, even if the editor shuts down the protocol and closes our stdin, and the main thread recognizes that. Instead, let's wait 60 seconds for threads to finish cleanly, and then crash if they haven't. (Obviously, we should still fix these bugs). Reviewers: kadircet Subscribers: MaskRay, jkorous, arphaman, jfb, usaxena95, cfe-commits, ilya-biryukov Tags: #clang Differential Revision: https://reviews.llvm.org/D69329
… pass against the latest version of D68233.
Summary: So far we rely on the default argument and the fact that we don't call this inline function in our actual `main.cpp` to make sure that this function can only be called if LLDB loads this header as a C++ module. This patch just adds the nodebug attribute as yet another measure to make sure LLDB can't call this function without the standard module loaded. Note that the test is already requiring clang for the sysroot setup, so its fine that this is a Clang specific attribute. Reviewers: friss, labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68861
…c' can be folded into the x node." This broke various Windows builds, see comments on the Phabricator review. This also reverts the follow-up 20bf0cf. > Summary: > This fold, helps recover from the rest of the D62266 ARM regressions. > https://rise4fun.com/Alive/TvpC > > Note that while the fold is quite flexible, i've restricted it > to the single interesting pattern at the moment. > > Reviewers: efriedma, craig.topper, spatel, RKSimon, deadalnix > > Reviewed By: deadalnix > > Subscribers: javed.absar, kristof.beyls, llvm-commits > > Tags: #llvm > > Differential Revision: https://reviews.llvm.org/D62450
(And test my commit access. We're working on larger changes here.)
This patch was reviewed and approved by chandlerc. "Getting Started with the LLVM System" is the first point of contact for many newcomers in the LLVM community. * Make the first two paragraphs more welcoming * Use more inclusive language
Summary: nm is one of the tools that extract_symbols.py can use to extract symbols from llvm libraries as part of the build process. This patch updates the invocation of nm to use the -P POSIX option for "portable output" so we get a consistently parsable output format on all platforms. A link to the relevant nm format: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html Reviewers: hubert.reinterpretcast, stevewan, sfertile Reviewed By: stevewan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69004
…in wording. Summary: Working with Meike and others to improve the wording in this document. Reviewers: klimek Subscribers: mcrosier, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69351
Reviewed and approved by chandlerc. As GitHub is the canonical LLVM repository now, embrace GitHub's way of displaying basic build instructions in the top-level readme.md.
Resolve conflict in README.md Signed-off-by: Vladimir Lazarev <[email protected]>
llvm: dc1499b spirv-translator: e7a8ed81
Add support for fneg operation. Signed-off-by: Vladimir Lazarev <[email protected]>
Fznamznon
approved these changes
Oct 25, 2019
vmaksimo
pushed a commit
to vmaksimo/llvm
that referenced
this pull request
Oct 12, 2020
* Add llvm.abs.i32 intrinsic translation Add translation of @llvm.abs.* to `s_abs` extended instruction. Signed-off-by: amochalo <[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: dc1499b
spirv-translator: e7a8ed81