Update to latest upstream master #18
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
Summary: Fix build problems encountered on osx in two files. The one in character.cpp fixes a legitimate bug that elicited a valid warning. Reviewers: tskeith, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby Reviewed By: tskeith, PeteSteinfeld Subscribers: llvm-commits, flang-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D82107
Add a simple CMakeLists.txt to build the runtimes in lockstep without building all of LLVM. See [1] for details. [1]: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142384.html
Reviewers: arsenm Subscribers: wdng, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82025
Summary: When enabling some malloc debug features on Android, multiple 32 bit regions become exhausted, and the allocations fail. Allow allocations to keep trying each bigger class in the Primary until it finds a fit. In addition, some Android tests running on 32 bit fail sometimes due to a running out of space in two regions, and then fail the allocation. Reviewers: cryptoad Reviewed By: cryptoad Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D82070
Reviewers: gribozavr2 Reviewed By: gribozavr2 Subscribers: hlopko, gribozavr2, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81168
…tination Sometimes a dead block gets folded and the debug information is still retained. This manifests as jumpy stepping in lldb, see the bugzilla PR for an end-to-end C testcase. Fixes https://bugs.llvm.org/show_bug.cgi?id=46008 Differential Revision: https://reviews.llvm.org/D82062
This should probably be implied for all the speculatable ones. I think the only ones where this plausibly doesn't apply is s_sendmsghalt and maybe kill.
…icate type; NFC The predicate can always be used to distinguish between icmp and fcmp, so we don't need to keep repeating this check in the callers.
This functionality is very similar to Function compatibility with AnnotationWriter. This change allows us to use AnnotationWriter with BasicBlock through BB.print() method. Reviewed-By: apilipenko Differntial Revision: https://reviews.llvm.org/D81321
If one uses an OpVariable (such as via Res) then the result type constraint should be returned. Differential Revision: https://reviews.llvm.org/D82119
muladd can have differenti types for lhs/rhs and acc/destination. Change verifier and update the test to use supported example. Differential Revision: https://reviews.llvm.org/D82042
Some projects use the constructor attribute on functions that also return values. In this case we just ignore them. The error was reported in the libgpg-error project that marks gpg_err_init with the `__constructor__` attribute. Differential Revision: https://reviews.llvm.org/D81962
This reverts: 8374bf4 [CodeView] Fix generated command-line expansion in LF_BUILDINFO. Fix the 'pdb' entry which was previously a null reference, now an empty string. 403f953 [CodeView] Add full repro to LF_BUILDINFO record This is causing the lld/test/COFF/pdb-relative-source-lines.test to fail: http://lab.llvm.org:8011/builders/lld-x86_64-win/builds/1096/steps/test-check-all/logs/FAIL%3A%20lld%3A%3Apdb-relative-source-lines.test And clang/test/CodeGen/debug-info-codeview-buildinfo.c fails as well: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/33346/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-codeview-buildinfo.c
…an runner This extends the types supported as kernel arguments when using vulkan runner. Differential Revision: https://reviews.llvm.org/D82068
Enable -amdgpu-internalize-symbols to eliminate unused functions and global variables for whole program to speed up compilation and improve performance. For -fno-gpu-rdc, -amdgpu-internalize-symbols is passed to clang -cc1. For -fgpu-rdc, -amdgpu-internalize-symbols is passed to lld. Differential Revision: https://reviews.llvm.org/D81959
Reviewers: efriedma, c-rhodes, david-arm, Tyker, asbirlea Reviewed By: david-arm Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82057
Reviewers: ftynse, nicolasvasilache, reidtatge Reviewed By: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes Tags: #mlir Differential Revision: https://reviews.llvm.org/D82117
…X as UNSUPPORTED for shtest-format-argv0 Summary: lit test `shtest-format.py` fails on AIX because one of the subtest of shtest-format requires the tool `[` to be installed under the system PATH. For AIX, `[` is only available as a shell builtin and does not present as an executable file under PATH. Hence, split the original shtest-format into two separate test files and added AIX as UNSUPPORTED for the test using `[` . Reviewers: daltenty, hubert.reinterpretcast Reviewed By: hubert.reinterpretcast Subscribers: delcypher, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82100
…ass. This class enables for abstracting more of the details for the rewrite process, and will allow for clients to apply specific cost models to the pattern list. This allows for DialectConversion and the GreedyPatternRewriter to share the same underlying matcher implementation. This also simplifies the plumbing necessary to support dynamic patterns. Differential Revision: https://reviews.llvm.org/D81985
Traditionally patterns have always had the root operation kind hardcoded to a specific operation name. This has worked well for quite some time, but it has certain limitations that make it undesirable. For example, some lowering have the same implementation for many different operations types with a few lowering entire dialects using the same pattern implementation. This problem has led to several "solutions": a) Provide a template implementation to the user so that they can instantiate it for each operation combination, generally requiring the inclusion of the auto-generated operation definition file. b) Use a non-templated pattern that allows for providing the name of the operation to match - No one ever does this, because enumerating operation names can be cumbersome and so this quickly devolves into solution a. This revision removes the restriction that patterns have a hardcoded root type, and allows for a class patterns that could match "any" operation type. The major downside of root-agnostic patterns is that they make certain pattern analyses more difficult, so it is still very highly encouraged that an operation specific pattern be used whenever possible. Differential Revision: https://reviews.llvm.org/D82066
Existing implementation of affine loop nest builders relies on EDSC ScopedContext, which is not used pervasively. Provide a common OpBuilder-based helper function to construct a perfect nest of affine loops with the body of the innermost loop populated by a callback. Use this function to implement the EDSC version. Affine "for" loops differ from SCF "for" loops by (1) not allowing to yield values and (2) supporting short-hand form for constant bounds, which justifies a separate implementation of the loop nest builder for the same of simplicity. Differential Revision: https://reviews.llvm.org/D81955
We recently introduced support for building loops or loop nests using callbacks that populate the body. Use these in the tutorial instead of setInsertionPoint manipulations. Differential Revision: https://reviews.llvm.org/D82104
Update the Sphinx configuration for the removal of source_parsers in Sphinx 3.0. The variable has been deprecated since version 1.8. > Version 1.8 deprecates and version 3.0 removes the source_parsers > configuration variable that was used by older recommonmark versions. https://www.sphinx-doc.org/en/master/usage/markdown.html Differential revision: https://reviews.llvm.org/D75284
Summary: Restructure HowToUpdateDebugInfo.rst to specify rules for when transformations should preserve, merge, or drop debug locations. The goal is to have clear, well-justified rules that come with a few examples and counter-examples, so that pass authors can pick the best strategy for managing debug locations depending on the specific task at hand. I've tried to set down sensible rules here that mostly align with what we already do in llvm today, and that take a diverse set of use cases into account (interactive debugging, crash triage, SamplePGO). Please *do* try to pick these rules apart and suggest clarifications or improvements :). Side note: Prior to 24660ea, this document was structured as a long list of very specific code transformations -- the idea being that we would fill in what to do in each specific case. I chose to reorganize the document as a list of actions to take because it drastically cuts down on the amount of redundant exposition/explanation needed. I hope that's fine... Reviewers: jmorse, aprantl, dblaikie Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81198
This was passing in all the parameters needed to construct a LegalizerHelper in the custom legalization, when it's simpler to just pass in the existing helper. This is slightly more annoying to use in the common case where you don't need the legalizer helper, but we could add back the common parameters back in addition to the helper. I didn't propagate this to all the internal target changes that this logically implies, but did update a sample one for legalizeMinNumMaxNum. This is in preparation for moving AMDGPU load/store legalization entirely into custom lowering. The current set of legalization actions is really constraining and not really capable of expressing all the actions needed to legalize loads/stores. In particular there's no way to express when the memory access itself needs to change size vs. the result type. There's also a lot of redundancy since the same split/widen actions need to be applied in both vector and scalar cases. All of the sub-cases logically belong as steps in the legalizer helper, but it will be easier to consider everything at once in custom lowering.
In one case, UpdateDefs was not getting set and a dead SmallVector constructed. In another, it was adding new vreg defs to the updated set which should be unnecessary. This also wasn't considering the multiple defs of G_UNMERGE_VALUES. Also increase the small vector sizes for merge/unmerge operands to the usual semi-arbitrary 8. While debugging these, I'm usually seeing merges and unmerges with at least 4 uses/defs. I haven't run into an actual problem from any of these though.
…n LLVM/Clang This patch implements builtins for the following prototypes: vector unsigned long long vec_pdep(vector unsigned long long, vector unsigned long long); vector unsigned long long vec_pext(vector unsigned long long, vector unsigned long long __b); unsigned long long __builtin_pdepd (unsigned long long, unsigned long long); unsigned long long __builtin_pextd (unsigned long long, unsigned long long); Revision Depends on D80758 Differential Revision: https://reviews.llvm.org/D80935
Summary: Fix several bugs in the Fortran runtime found in initial testing. Reviewers: tskeith, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby Reviewed By: tskeith, PeteSteinfeld Subscribers: llvm-commits, flang-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D82116
I don't know anything about debug info, but this seems like more work should be necessary. This constructs a new IRBuilder and reconstructs the original divides rather than moving the original. One problem this has is if a div/rem pair are handled, both end up with the same debugloc. I'm not sure how to fix this, since this uses a cache when it sees the same input operands again, which will have the first instance's location attached.
It is "trailing objects" and "tail-allocated storage".
The serialization of ConstantExpr has currently a number of problems: - Some fields are just not serialized (ConstantExprBits.APValueKind and ConstantExprBits.IsImmediateInvocation). - ASTStmtReader::VisitConstantExpr forgets to add the trailing APValue to the list of objects to be destroyed when the APValue needs cleanup. While we are at it, bring the serialization of ConstantExpr more in-line with what is done with the other expressions by doing the following NFCs: - Get rid of ConstantExpr::DefaultInit. It is better to not initialize the fields of an empty ConstantExpr since this will allow msan to detect if a field was not deserialized. - Move the initialization of the fields of ConstantExpr to the constructor; ConstantExpr::Create allocates the memory and ConstantExpr::ConstantExpr is responsible for the initialization. Review after commit since this is a straightforward mechanical fix similar to the other serialization fixes.
Remove the space after the "CHECK:" on each line. This space makes the use of FileCheck --match-full-lines impossible.
…t 2/n. The outputs between the direct ast-dump test and the ast-dump test after deserialization should match modulo a few differences. For hand-written tests, strip the "<undeserialized declarations>"s and the "imported"s with sed. For tests generated with "make-ast-dump-check.sh", regenerate the output. Part 2/n.
…t 3/n. The outputs between the direct ast-dump test and the ast-dump test after deserialization should match modulo a few differences. For hand-written tests, strip the "<undeserialized declarations>"s and the "imported"s with sed. For tests generated with "make-ast-dump-check.sh", regenerate the output. Part 3/n.
(The 'nnan' variant of this pattern is already tested to produce '1.0'.) https://alive2.llvm.org/ce/z/D4hPBy define i1 @src(float %x, i32 %y) { %0: %d = fdiv float %x, %x %uge = fcmp uge float %d, 0.000000 ret i1 %uge } => define i1 @tgt(float %x, i32 %y) { %0: ret i1 1 } Transformation seems to be correct!
This reverts commit 7348b95. It is causing Asan failures.
GetUnderlyingObject() (and by required symmetry DecomposeGEPExpression()) will call SimplifyInstruction() on the passed value if other checks fail. This simplification is very expensive, but has little effect in practice. This patch removes the SimplifyInstruction call(), and replaces it with a check for single-argument phis (which can occur in canonical IR in LCSSA form), which is the only useful simplification case I was able to identify. At O3 the geomean CTMark improvement is -1.7%. The largest improvement is SPASS with ThinLTO at -6%. In test-suite, I see only two tests with a hash difference and no code size difference (PAQ8p, Ptrdist), which indicates that the simplification only ends up being useful very rarely. (I would have liked to figure out which simplification is responsible here, but wasn't able to spot it looking at transformation logs.) The AMDGPU test case that is update was using two selects with undef condition, in which case GetUnderlyingObject will return the first select operand as the underlying object. This will of course not happen with non-undef conditions, so this was not testing anything realistic. Additionally this illustrates potential unsoundness: While GetUnderlyingObject will pick the first operand, the select might be later replaced by the second operand, resulting in inconsistent assumptions about the undef value. Differential Revision: https://reviews.llvm.org/D82261
If a collection of interconnected phi nodes is only ever loaded, stored or bitcast then we can convert the whole set to the bitcast type, potentially helping to reduce the number of register moves needed as the phi's are passed across basic block boundaries. This has to be done in CodegenPrepare as it naturally straddles basic blocks. The alorithm just looks from phi nodes, looking at uses and operands for a collection of nodes that all together are bitcast between float and integer types. We record visited phi nodes to not have to process them more than once. The whole subgraph is then replaced with a new type. Loads and Stores are bitcast to the correct type, which should then be folded into the load/store, changing it's type. This comes up in the biquad testcase due to the way MVE needs to keep values in integer registers. I have also seen it come up from aarch64 partner example code, where a complicated set of sroa/inlining produced integer phis, where float would have been a better choice. I also added undef and extract element handling which increased the potency in some cases. This adds it with an option that defaults to off, and disabled for 32bit X86 due to potential issues around canonicalizing NaNs. Differential Revision: https://reviews.llvm.org/D81827
Add -fpch-instantiate-templates which makes template instantiations be performed already in the PCH instead of it being done in every single file that uses the PCH (but every single file will still do it as well in order to handle its own instantiations). I can see 20-30% build time saved with the few tests I've tried. The change may reorder compiler output and also generated code, but should be generally safe and produce functionally identical code. There are some rare cases that do not compile with it, such as test/PCH/pch-instantiate-templates-forward-decl.cpp. If template instantiation bailed out instead of reporting the error, these instantiations could even be postponed, which would make them work. Enable this by default for clang-cl. MSVC creates PCHs by compiling them using an empty .cpp file, which means templates are instantiated while building the PCH and so the .h needs to be self-contained, making test/PCH/pch-instantiate-templates-forward-decl.cpp to fail with MSVC anyway. So the option being enabled for clang-cl matches this. Differential Revision: https://reviews.llvm.org/D69585
As we traverse the CFG backwards, we could end up reaching unreachable blocks. For unreachable blocks, we won't have computed post order numbers and because DomAccess is reachable, unreachable blocks cannot be on any path from it. This fixes a crash with unreachable blocks.
-target must match between PCH creation and use.
Just adds the storeOptions for Checks that weren't already storing their options. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D82223
libgcc has this enum encoding defined for a while, but their detection code is missing. I've raised a bug with them so that should get fixed soon.
Cooperlake can be detect by compiler-rt now, but not libgcc yet. Tigerlake can't be detected by either. Both names are accepted by gcc. Hopefully the detection code will be in place soon.
This doesn't change anything currently, but it would make sense to create a class-level IRBuilder instead of recreating that everywhere. As we expand to more optimizations, we will probably also want to hold things like the DataLayout or other constant refs in here too.
…n used with function multiversioning Also test cooperlake since it was also just added to function multiversioning when it was enabled for __builtin_cpu_is.
I forgot to do this when I added then to _cpu_indicator_init.
haoyouab
pushed a commit
to Flex-plaidml-team/llvm-project
that referenced
this pull request
Sep 4, 2020
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned `entry_addr` is valid, it can immediately be returned. However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: ``` * thread plaidml#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 plaidml#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 plaidml#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 plaidml#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 plaidml#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 plaidml#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 plaidml#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 plaidml#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 plaidml#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 plaidml#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 plaidml#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 plaidml#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 plaidml#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 plaidml#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 plaidml#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 plaidml#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 plaidml#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 plaidml#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 plaidml#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 plaidml#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 plaidml#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 plaidml#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 plaidml#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 plaidml#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 plaidml#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 plaidml#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890``` Fix the incorrect error catch by only instantiating an `Error` object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355
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.
No description provided.