llvm-svn: 354059

For "idempotent" atomicrmw instructions which we can't simply turn into load, canonicalize the operation and constant. This reduces the matching needed elsewhere in the optimizer, but doesn't directly impact codegen.

For any architecture where OR/Zero is not a good default choice, you can extend the AtomicExpand lowerIdempotentRMWIntoFencedLoad mechanism. I reviewed X86 to make sure this works well, haven't audited other backends.

Differential Revision: https://reviews.llvm.org/D58244

llvm-svn: 354058

If you want to build clang-tools-extra with monorepo, just add it to
LLVM_ENABLE_PROJECTS like with other projects.

See also "Separating clang-tools-extra from clang in LLVM_ENABLE_PROJECTS"
on cfe-dev.

Differential Revision: https://reviews.llvm.org/D58157

llvm-svn: 354057

llvm-svn: 354055

Unfortunately the original code gets misscompiled by GCC (at least 8.1),
this is a tentative workaround using std::memcpy instead of inplace new
for trivially copyable types. I'll revert if it breaks.

Original revision: https://reviews.llvm.org/D57097

llvm-svn: 354051

Expand on Quentin's r353471 patch which converts some atomicrmws into loads. Handle remaining operation types, and fix a slight bug. Atomic loads are required to have alignment. Since this was within the InstCombine fixed point, somewhere else in InstCombine was adding alignment before the verifier saw it, but still, we should fix.

Terminology wise, I'm using the "idempotent" naming that is used for the same operations in AtomicExpand and X86ISelLoweringInfo. Once this lands, I'll add similar tests for AtomicExpand, and move the pattern match function to a common location. In the review, there was seemingly consensus that "idempotent" was slightly incorrect for this context.  Once we setle on a better name, I'll update all uses at once.

Differential Revision: https://reviews.llvm.org/D58242

llvm-svn: 354046

Always use the internal `call_once` for PPC64le.  This is needed to
support the Swift toolchain on PPC64le.

Patch by Sarvesh Tamba!

llvm-svn: 354045

Summary:
GNU ar has a `P` modifier that changes filename comparisons to use full paths instead of the basename. As noted in the GNU docs, regular archives are not created with full path names, so P is used to deal with archives created by other archive programs (e.g. see the updated `absolute-paths.test` test case).

Since thin archives use full path names -- paths are relative to the archive -- it seems very error prone to not imply P when dealing with thin archives, so P is implied in those cases. (I think this is a deviation from GNU ar that makes sense).

This fixes PR37436 via https://github.com/ClangBuiltLinux/linux/issues/33.

Reviewers: mstorsjo, pcc, ruiu, davide, david2050, rnk

Subscribers: tpimh, llvm-commits, nickdesaulniers

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57927

llvm-svn: 354044

llvm-svn: 354042

Review: Ulrich Weigand
https://reviews.llvm.org/D58240

llvm-svn: 354039

Base for a followup patch to strengthen the InstCombine transform, and then integrate the ExpandAtomics logic.

llvm-svn: 354036

llvm-svn: 354034

Summary:
In r353537 we now copy all metadata to the new function, with the old
being removed when the old function is eliminated. In some cases the old
function is dropped to a declaration (seems to only occur with the old
PM). Go ahead and clear all metadata from the old function to handle that
case, since verification will complain otherwise. This is consistent
with what was being done for debug metadata before r353537.

Reviewers: davidxl, uabelho

Subscribers: jdoerfert, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58215

llvm-svn: 354032

The test case requires the peeled loop to be forgotten after peeling,
even though it does not have a parent. When called via the unroller,
SE->forgetTopmostLoop is also called, so the test case would also pass
without any SCEV invalidation, but peelLoop is exposed as utility
function. Also, in the test case, simplifyLoop will make changes,
removing the loop from SCEV, but it is better to not rely on this
behavior.

Reviewers: sanjoy, mkazantsev

Reviewed By: mkazantsev

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58192

llvm-svn: 354031

llvm-svn: 354028

This reverts commit r351091.
The original mac breakages are addressed by ensuring the root directory
we're working from is fully symlink-resolved before starting.

Differential Revision: https://reviews.llvm.org/D58169

llvm-svn: 354026

Select G_PHI for integers for MIPS32.

Differential Revision: https://reviews.llvm.org/D58183

llvm-svn: 354025

lib/Transforms/Instrumentation/AddressSanitizer.cpp:1173:29: warning: extra ‘;’ [-Wpedantic]

llvm-svn: 354024

Select G_BR and G_BRCOND for MIPS32.
Unconditional branch G_BR does not have register operand,
for that reason we only add tests.
Since conditional branch G_BRCOND compares register to zero on MIPS32,
explicit extension must be performed on i1 condition in order to set
high bits to appropriate value.

Differential Revision: https://reviews.llvm.org/D58182

llvm-svn: 354022

Side effects of widenable condition intrinsic are modelled via
InaccessibleMemOnly, and there is no way to say that it isn't
really writing any memory. This patch teaches MemoryWriteTracking
ignore this intrinsic.

llvm-svn: 354021

Widenable condition intrinsic is guaranteed to return value, notify
the isGuaranteedToTransferExecutionToSuccessor function about it.

llvm-svn: 354020

While rebasing a refactor in r353950 I accidentally swapped two function
arguments; one is SelectionDAGBuilders "current" DebugLoc, the other is the one
from the "current" debug intrinsic. They're probably always identical, but I
haven't proved that yet.

llvm-svn: 354019

The Arm peephole optimiser code keeps track of both an MI and a SubAdd that can
be used to optimise away a CMP. In the rare case that both are found and not
ruled-out as valid, we could end up setting the flags on the wrong one.

Instead make sure we are using SubAdd if it exists, as it will be closer to the
CMP.

The testcase here is a little theoretical, with a dead def of cpsr. It should
hopefully show the point.

Differential Revision: https://reviews.llvm.org/D58176

llvm-svn: 354018

Moved the remove of the temporary file to after the close to avoid
remove failures caused by ETXTBSY errors.

This issue was seen when FileOutputBuffer falls back to an in memory
buffer due to the inability to mmap the on disk file. This occurred when
running LLD on an Ubuntu VM in VirtualBox on a Windows host attempting
to write the output to a VirtualBox shared folder.

Differential Revision: https://reviews.llvm.org/D57960

llvm-svn: 354017

llvm-svn: 354013

And delete trailing whitespace

llvm-svn: 354011

to be like every other check in this test.

llvm-svn: 354007

[X86] Make (f80 (sint_to_fp (i16))) use fistps/fisttps instead of fistpl/fisttpl when SSE is enabled.

When SSE is enabled sint_to_fp with i16 is blindly promoted to i32, but that changes the behavior of f80 conversion.

Move the promotion to i16 to LowerFP_TO_INT so we can limit it based on the floating point type.

llvm-svn: 354003

Reverted due to failures on the llvm-hexagon-elf.

This reverts commit 77e1f274.

llvm-svn: 354002

Summary:

https://bugs.llvm.org/show_bug.cgi?id=31679

Reviewers: kristina, jhenderson, grimar, jakehehrlich, rupprecht

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57904

llvm-svn: 353998

Summary:
The declarative tablegen definitions split rules into match and apply steps.
Prepare for that by doing the same in the C++ implementations. This aids
some of the migration effort while the tablegen version is incomplete.

Reviewers: bogner, volkan, aditya_nandakumar, paquette, aemerson

Reviewed By: aditya_nandakumar

Subscribers: rovka, kristof.beyls, Petar.Avramovic, jdoerfert, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58150

llvm-svn: 353996

Summary:
When adding one thin archive to another, we currently chop off the relative path to the flattened members. For instance, when adding `foo/child.a` (which contains `x.txt`) to `parent.a`, when flattening it we should add it as `foo/x.txt` (which exists) instead of `x.txt` (which does not exist).

As a note, this also undoes the `IsNew` parameter of handling relative paths in r288280. The unit test there still passes.

This was reported as part of testing the kernel build with llvm-ar: https://patchwork.kernel.org/patch/10767545/ (see the second point).

Reviewers: mstorsjo, pcc, ruiu, davide, david2050, inglorion

Reviewed By: ruiu

Subscribers: void, jdoerfert, tpimh, mgorny, hans, nickdesaulniers, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57842

llvm-svn: 353995

Added four test files to check the existing behaviour of prologue
and epilogue code generation. This patch was done as a setup for
the upcoming patch listed on Phabricator that will change how the
prologue and epilogue work.
The upcoming patch is: https://reviews.llvm.org/D42590

llvm-svn: 353994

A fix for these is proposed in D51216.

llvm-svn: 353992

Reviewers: grimar, rupprecht

Reviewed By: rupprecht

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58175

llvm-svn: 353991

For D57601, we need to know whether the instruction is volatile.  We'd either have to pass yet another parameter, or just standardize on the MMO interface.  I chose the second.

llvm-svn: 353989

Last chance recoloring inserts into FixedRegisters those virtual
registers it is attempting to assign a physical register to.

We must consider these when we consider candidates for eviction so that
we do not end up evicting something while we are attempting to recolor
to assign it.

This is hitting in an out-of-tree target and no longer reproduces on
trunk. That does not appear to be a result of it having been fixed, but
rather, it appears that optimization changes and/or other changes to
register allocation mask the problem.

I haven't found a way to come up with a reasonable test case for this
(i.e. one that I can actually commit to open source, is reasonable
in size, and actually reproduces the issue).

rdar://problem/45708741

llvm-svn: 353988

llvm-svn: 353987

Summary:
memset lowering, fix argument types in memcpy lowering, and
test encodings. Depends on D57736.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57791

llvm-svn: 353986

This is the second attempt to port ASan to new PM after D52739. This takes the
initialization requried by ASan from the Module by moving it into a separate
class with it's own analysis that the new PM ASan can use.

Changes:
- Split AddressSanitizer into 2 passes: 1 for the instrumentation on the
  function, and 1 for the pass itself which creates an instance of the first
  during it's run. The same is done for AddressSanitizerModule.
- Add new PM AddressSanitizer and AddressSanitizerModule.
- Add legacy and new PM analyses for reading data needed to initialize ASan with.
- Removed DominatorTree dependency from ASan since it was unused.
- Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the
  new PM analysis holds these 2 classes and will need to expose them.

Differential Revision: https://reviews.llvm.org/D56470

llvm-svn: 353985