Feature/merge upstream 20210712 #73
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
Currently InstructionSimplify.cpp knows how to simplify floating point instructions that have a NaN operand. It does not know how to handle the matching constrained FP intrinsic. This patch teaches it how to simplify so long as the exception handling is not "fpexcept.strict". Differential Revision: https://reviews.llvm.org/D103169
GetElementPtrInst::Create() (and IRBuilder methods based on it) currently accept nullptr as the element type, and will fetch the element type from the pointer in that case. Remove this fallback, as it is incompatible with opaque pointers. I've removed a handful of leftover calls using this behavior as a preliminary step. Out-of-tree code affected by this change should either pass a proper type, or can temporarily explicitly call getPointerElementType(), if the newly added assertion is encountered. Differential Revision: https://reviews.llvm.org/D105653
…hable"" This reverts commit 52aeacf. There isn't full agreement on a path forward yet, but there is agreement that this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338 Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality" This reverts commit f4877c7. And all the related changes to tests: This reverts commit 9a01527. This reverts commit 3f7c9cc. This reverts commit 329f819. This reverts commit aa9f58c. This reverts commit 2df37d5. This reverts commit a72a441.
While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
LLVM IR allows globals with external linkage to have initializers, including undef. The translation was incorrectly using undef as a indicator that the initializer should be ignored in translation, leading to the impossibility to create an external global with an explicit undef initializer. Fix this and use nullptr as a marker instead. Reviewed By: wsmoses Differential Revision: https://reviews.llvm.org/D105631
Use a modeling similar to SCF ParallelOp to support arbitrary parallel reductions. The two main differences are: (1) reductions are named and declared beforehand similarly to functions using a special op that provides the neutral element, the reduction code and optionally the atomic reduction code; (2) reductions go through memory instead because this is closer to the OpenMP semantics. See https://llvm.discourse.group/t/rfc-openmp-reduction-support/3367. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D105358
Instead of printing each region individually when using JSON format, this patch creates a JSON object which is updated with the values of each region, printing them at the end. New test is added for JSON output with multiple regions. Bug: https://bugs.llvm.org/show_bug.cgi?id=51008 Reviewed By: andreadb Differential Revision: https://reviews.llvm.org/D105618
Because of https://reviews.llvm.org/D104500, libc++ is broken with recent Clangs in C++03 mode.
This is a simple enum attribute. Test changes are because enum attributes are sorted before type attributes.
Some buildbots fail with undefined references to ByValTypeIndex etc. Replace static consts with an enum to ensure the address is not taken.
byval's type parameter is now always required.
This is NFC-intended currently (so no test diffs). The motivation is to eventually allow matching for poison-safe logical-and and logical-or (these are in the form of a select-of-bools). ( https://llvm.org/PR41312 ) Those patterns will not have all of the same constraints as min/max in the form of cmp+sel. We may also end up removing the cmp+sel min/max matching entirely (if we canonicalize to intrinsics), so this will make that step easier.
This reverts commit 84ed3a7. A number of clang tests are also affected by this change. Revert until I can update them.
This likely started out only supporint binops, but now we handle min/max using cmp+sel, and we may extend to handle bool logic in the form of select.
Instead of getType()->getElementType().
…7a00e2deba65
Fails with:
```
/build/llvm-toolchain-snapshot-13~++20210709092633+88326bbce38c/llvm/lib/Target/M68k/GlSel/M68kCallLowering.cpp: In member function 'virtual bool llvm::M68kCallLowering::lowerReturn(llvm::MachineIRBuilder&, const llvm::Value*, llvm::ArrayRef<llvm::Register>, llvm::FunctionLoweringInfo&, llvm::Register) const':
/build/llvm-toolchain-snapshot-13~++20210709092633+88326bbce38c/llvm/lib/Target/M68k/GlSel/M68kCallLowering.cpp:71:42: error: no matching function for call to 'llvm::CallLowering::ArgInfo::ArgInfo(<brace-enclosed initializer list>)'
ArgInfo OrigArg{VRegs, Val->getType()};
```
Differential Revision: https://reviews.llvm.org/D105689
Add the ability to silence command script import. The motivation for this change is being able to add command script import -s lldb.macosx.crashlog to your ~/.lldbinit without it printing the following message at the beginning of every debug session. "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help. In addition to forwarding the silent option to LoadScriptingModule, this also changes ScriptInterpreterPythonImpl::ExecuteOneLineWithReturn and ScriptInterpreterPythonImpl::ExecuteMultipleLines to honor the enable IO option in ExecuteScriptOptions, which until now was ignored. Note that IO is only enabled (or disabled) at the start of a session, and for this particular use case, that's done when taking the Python lock in LoadScriptingModule, which means that the changes to these two functions are not strictly necessary, but (IMO) desirable nonetheless. Differential revision: https://reviews.llvm.org/D105327
Similar to D104889. The tool is very simple and its long options are uncommon, so just drop the one-dash form in this patch. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D105605
LLVM provides target hooks to recognise stack spill and restore instructions, such as isLoadFromStackSlot, and it also provides post frame elimination versions such as isLoadFromStackSlotPostFE. These are supposed to return the store-source and load-destination registers; unfortunately on X86, the PostFE recognisers just return "1", apparently to signify "yes it's a spill/load". This patch alters the hooks to correctly return the store-source and load-destination registers: This is really useful for debug-info as we it helps follow variable values as they move on/off the stack. There should be no codegen changes: the only other users of these PostFE target hooks are MachineInstr::getRestoreSize and MachineInstr::getSpillSize, which don't attempt to interpret the returned register location. While we're here, delete the (InstrRef) LiveDebugValues heuristic that tries to find the spill source register by looking for a killed reg -- we should be able to rely on the target hooks for that. This involves temporarily turning off a n InstrRef LivedDebugValues test on aarch64 (patch to re-enable it is in D104521). Differential Revision: https://reviews.llvm.org/D105428
This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`. Differential Revision: https://reviews.llvm.org/D105597
Reviewed By: cjdb, ldionne, #libc Differential Revision: https://reviews.llvm.org/D103056
Part of https://lists.llvm.org/pipermail/llvm-dev/2021-July/151622.html "Binary utilities: switch command line parsing from llvm::cl to OptTable" * `--totals=false` and `--totals=0` cannot be used. Omit the option. * `--help-list` is removed. This is a `cl::` specific option. OptTable avoids global option collision if we decide to support multiplexing for binary utilities. Note: because the tool is simple, and its long options are uncommon, I just drop the one-dash forms except `-arch <value>` (Darwin style). Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D105598
The documentation for the AMDGPU assembler's examples don't show the .args section, which, if ommitted, will cause arguments to silently not be passed into the kernel. This commit fixes this issue. Reviewed By: #amdgpu, scott.linder Differential Revision: https://reviews.llvm.org/D105222
This can be moved out of hwasan_linux.cpp because it can be re-used in the fuchsia port. Differential Revision: https://reviews.llvm.org/D105669
The new name is something less linux-y and more platform generic. Once we finalize the tagged pointer ABI in zircon, we will do the appropriate check for fuchsia to see that TBI is enabled. Differential Revision: https://reviews.llvm.org/D105667
Based on comments in D91466, we can make the current implementation linux-speciic. The fuchsia implementation will just be a call to `__sanitizer_fill_shadow`. Differential Revision: https://reviews.llvm.org/D105663
Currently, `flang -c file.f` generates `flang_unparsed_source_file_0.o`.
This is incorrect. This patch:
* simplifies the logic around output filename generation, and
* makes sure that `file.o` is produced instead of e.g.
`flang_unparsed_source_file_0.o` when using the `-c` flag
The output filename generation is moved to a dedicated function. I've
also made a few minor improvements, e.g. marked variables as local,
added comments, refined error messages.
Differential Revision: https://reviews.llvm.org/D105546
…if there is a regmask operand that clobbers the FP stack. There are some calls to functions like `__alloca` that are missing a regmask operand. Lack of a regmask operand means that all registers that aren't mentioned by def operands are preserved. __alloca only updates EAX and ESP and has def operands for them so this is ok. Because there is no regmask the register allocator won't spill the FP registers across the call. Assuming we want to keep the FP stack untoched across these calls, we need to handle this is in the FP stackifier. We might want to add a proper regmask operand to the code that creates these calls to indicate all registers are preserved, but we'd still need this change to the FP stackifier to know to preserve the FP stack for such a regmask. The test is kind of long, but bugpoint wasn't able to reduce it any further. Fixes PR50782 Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D105762
This way, other platforms can define these values. Differential Revision: https://reviews.llvm.org/D105744
Currently we allocate MemoryMapper per size class. MemoryMapper mmap's and munmap's internal buffer. This results in 50 mmap/munmap calls under the global allocator mutex. Reuse MemoryMapper and the buffer for all size classes. This radically reduces number of mmap/munmap calls. Smaller size classes tend to have more objects allocated, so it's highly likely that the buffer allocated for the first size class will be enough for all subsequent size classes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D105778
Replace the clang builtin function and LLVM intrinsic for
f32x4.demote_zero_f64x2 with combines from normal SDNodes. Also add missing
combines for i32x4.trunc_sat_zero_f64x2_{s,u}, which share the same pattern.
Differential Revision: https://reviews.llvm.org/D105755
Differential Revision: https://reviews.llvm.org/D105818
The lowering for v2i64 is now guarded with hasDirectMove, however, the current lowering can handle the pattern correctly, only lowering it when there is efficient patterns and corresponding instructions. The original guard was added in D21135, and was for Legal action. The code has evloved now, this guard is not necessary anymore. Reviewed By: #powerpc, nemanjai Differential Revision: https://reviews.llvm.org/D105596
This reverts commit 0726695. This causes the following build failure with gcc 10.3.0: /home/nikic/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_allocator_primary64.h:114:31: error: declaration of ‘typedef class __sanitizer::MemoryMapper<__sanitizer::SizeClassAllocator64<Params> > __sanitizer::SizeClassAllocator64<Params>::MemoryMapper’ changes meaning of ‘MemoryMapper’ [-fpermissive] 114 | typedef MemoryMapper<ThisT> MemoryMapper;
Bazel configuration updates for llvm/llvm-project@75e5f0aac97d, llvm/llvm-project@c282d55a3857, and llvm/llvm-project@26e59cc19f86 Tested: `bazel test ... @llvm-project//...` Differential Revision: https://reviews.llvm.org/D105830
Followup to D105658 to make AttrBuilder automatically work with new type attributes. TableGen is tweaked to emit First/LastTypeAttr markers, based on which we can handle type attributes programmatically. Differential Revision: https://reviews.llvm.org/D105763
Reviewed By: xgupta Differential Revision: https://reviews.llvm.org/D105825
Breaks https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-android This reverts commit 6062c67. This reverts commit 8e489b4.
Assert that enum/int/type attributes go through the constructor they are supposed to use. To make sure this can't happen via invalid bitcode, explicitly verify that the attribute kind if correct there.
It's not necessary to explicitly sort by enum/int/type attribute, as the attribute kinds are already sorted this way. We can directly sort by kind.
On AIX when there is a pragma pack, or pragma align in effect then zero-width bitfields should pad out to the end of the bitfield container but not increase the alignment requirements of the struct greater then the max field align. Reviewed By: ZarkoCA Differential Revision: https://reviews.llvm.org/D105635
This change is a step towards implementing codegen for __builtin_clz(). Full support for CLZ with a regression test will follow shortly. Differential Revision: https://reviews.llvm.org/D105560
…n llvm-mca reports. Update (mainly) vXf32/vXf64 -> vXi8/vXi16 fptosi/fptoui costs based on the worst case costs from the script in D103695. Move to using legalized types wherever possible, which allows us to prune the cost tables.
llvm/llvm-project@5208ec5c66dc updated the of google-benchmark under libcxx adding a BUILD.bazel file. This upsets Bazel in our overlay configuration because it tries to interpret this file. Currently this is breaking the CI: https://buildkite.com/llvm-project/upstream-bazel-rbe/builds/1828 Tested (same command the CI uses) `bazel query //... + @llvm-project//... | xargs bazel test --config=generic-clang --config=rbe --test_output=errors --test_tag_filters=-nobuildkite --build_tag_filters=-nobuildkite` Differential Revision: https://reviews.llvm.org/D105833
This is now the same as isIntAttrKind(), so use that instead, as it does not require manual maintenance. The naming is also more accurate in that both int and type attributes have an argument, but this method was only targeting int attributes. I initially wanted to tighten the AttrBuilder assertion, but we have some in-tree uses that would violate it.
InAlloca was listed twice, once as a normal attribute, once as a type attribute.
…nt state of the world. Marks a few things as done. Marks a few things as in progress. Assigns a few things to me.
…merge-upstream-20210712
kaz7
pushed a commit
that referenced
this pull request
Jan 24, 2024
…vg (#70914) This removes explicit invalidation of vg and svg that was done in `GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact covering up a bug elsehwere. Register information says that a write to vg also invalidates svg (it does not unless you are in streaming mode, but we decided to keep it simple and say it always does). This invalidation was not being applied until *after* AArch64Reconfigure was called. This meant that without those manual invalidates this happened: * vg is written * svg is not invalidated * Reconfigure uses the written vg value * Reconfigure uses the *old* svg value I have moved the AArch64Reconfigure call to after we've processed the invalidations caused by the register write, so we no longer need the manual invalidates in AArch64Reconfigure. In addition I have changed the order in which expedited registers as parsed. These registers come with a stop notification and include, amongst others, vg and svg. So now we: * Parse them and update register values (including vg and svg) * AArch64Reconfigure, which uses those values, and invalidates every register, because offsets may have changed. * Parse the expedited registers again, knowing that none of the values will have changed due to the scaling. This means we use the expedited registers during the reconfigure, but the invalidate does not mean we throw all of them away. The cost is we parse them twice client side, but this is cheap compared to a network packet, and is limited to AArch64 targets only. On a system with SVE and SME, these are the packets sent for a step: ``` (lldb) b-remote.async> < 803> read packet: $T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:000000000040056c<...>a1:0800000000000000;d9:0400000000000000;reason:trace;#fc intern-state < 21> send packet: $xfffffffff200,200#5e intern-state < 516> read packet: $e4f2ffffffff000000<...>#71 intern-state < 15> send packet: $Z0,400568,4#4d intern-state < 6> read packet: $OK#9a dbg.evt-handler < 16> send packet: $jThreadsInfo#c1 dbg.evt-handler < 224> read packet: $[{"name":"main.o","reason":"trace","registers":{"161":"0800000000000000",<...>}],"signal":5,"tid":8064}]]#73 ``` You can see there are no extra register reads which means we're using the expedited registers. For a write to vg: ``` (lldb) register write vg 4 lldb < 37> send packet: $Pa1=0400000000000000;thread:1f80;#4a lldb < 6> read packet: $OK#9a lldb < 20> send packet: $pa1;thread:1f80;#29 lldb < 20> read packet: $0400000000000000#04 lldb < 20> send packet: $pd9;thread:1f80;#34 lldb < 20> read packet: $0400000000000000#04 ``` There is the initial P write, and lldb correctly assumes that SVG is invalidated by this also so we read back the new vg and svg values afterwards.
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.
Merge upstream/main up to 2021/7/12.
Pass regression tests.