Fix PR36119

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

llvm-svn: 359029

Before a Debugger gets a Target, target settings are routed to a global set
of settings. Even without this, some part of the LLDB which exist independently
of the Debugger object (the Module cache, the Symbol vendors, ...) access
directly the global default store for those settings.

Of course, if you modify one of those global settings while they are being read,
bad things happen. We see this quite a bit with FileSpecList settings. In
particular, we see many cases where one debug session changes
target.exec-search-paths while another session starts up and it crashes when
one of those accesses invalid FileSpecs.

This patch addresses the specific FileSpecList issue by adding locking to
OptionValueFileSpecList and never returning by reference.

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 359028

DominatorTree::dominate.

ARC contract pass has an optimization that replaces the uses of the
argument of an ObjC runtime function call with the call result.

For example:

; Before optimization
%1 = tail call i8* @foo1()
%2 = tail call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %1)
store i8* %1, i8** @g0, align 8

; After optimization
%1 = tail call i8* @foo1()
%2 = tail call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %1)
store i8* %2, i8** @g0, align 8 // %1 is replaced with %2

Before replacing the argument use, DominatorTree::dominate is called to
determine whether the user instruction is dominated by the ObjC runtime
function call instruction. The call to DominatorTree::dominate can be
expensive if the two instructions belong to the same basic block and the
size of the basic block is large. This patch checks the basic block size
and just bails out if the size exceeds the limit set by command line
option "arc-contract-max-bb-size".

rdar://problem/49477063

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

llvm-svn: 359027

Originally committed in r358931
Reverted in r358997

Seems this change made Apple accelerator tables miss names (because
names started respecting the CU NameTableKind GNU & assuming that
shouldn't produce accelerated names too), which is never correct (apple
accelerator tables don't have separators or CU lists - if present, they
must describe all names in all CUs).

Original Description:
Currently to opt in to debug_names in DWARFv5, the IR must contain
'nameTableKind: Default' which also enables debug_pubnames.

Instead, only allow one of {debug_names, apple_names, debug_pubnames,
debug_gnu_pubnames}.

nameTableKind: Default gives debug_names in DWARFv5 and greater,
debug_pubnames in v4 and earlier - and apple_names when tuning for lldb
on MachO.
nameTableKind: GNU always gives gnu_pubnames

llvm-svn: 359026

Summary:
The opt level was not being passed down to the ThinLTO backend when
invoked via clang (for distributed ThinLTO).

This exposed an issue where the new PM was asserting if the Thin or
regular LTO backend pipelines were invoked with -O0 (not a new issue,
could be provoked by invoking in-process *LTO backends via linker using
new PM and -O0). Fix this similar to the old PM where -O0 only does the
necessary lowering of type metadata (WPD and LowerTypeTest passes) and
then quits, rather than asserting.

Reviewers: xur

Subscribers: mehdi_amini, inglorion, eraman, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits, pcc

Tags: #clang, #llvm

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

llvm-svn: 359025

Before, there was an IsData parameter. Now, there are two different
functions for data nodes and ID nodes. No behavior change, needed for a
follow-up change to make two data nodes (but not two ID nodes) with the
same ID an error.

For consistency, rename another addChild() overload to addNameChild().

llvm-svn: 359024

llvm-svn: 359023

Add it to isPreISelGenericFloatingPointOpcode, and add a regbankselect test.

Update arm64-vfloatintrinsics.ll now that we can select it.

llvm-svn: 359022

Same patch as G_FCEIL etc.

Add the missing switch case in widenScalar, add G_INTRINSIC_TRUNC to the correct
rule in AArch64LegalizerInfo.cpp, and add a test.

llvm-svn: 359021

Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers. 

This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.

Suggestions for a cleaner implementation are welcome.

Reviewers: mclow.lists, ldionne

Reviewed By: ldionne

Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits

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

llvm-svn: 359020

Add urem support to ConstantRange, so we can handle in in LVI. This
is an approximate implementation that tries to capture the most useful
conditions: If the LHS is always strictly smaller than the RHS, then
the urem is a no-op and the result is the same as the LHS range.
Otherwise the lower bound is zero and the upper bound is
min(LHSMax, RHSMax - 1).

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

llvm-svn: 359019

Move Test(Unsigned|Signed)BinOpExhaustive() towards the top of the
file, so they're easier to reuse.

llvm-svn: 359018

The second argument is flags, not subreg.

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

llvm-svn: 359017

We recently moved API logging into the instrumentation macros. This made
that logging is now consistent and abstracted behind a macro for every
API functions, independent of the reproducers. It also means we have a
lot more output. While this is a good thing, it also meant a lot more
noise in the log, from things that aren't always equally interesting,
such as the copy constructor for example.

To improve usability, we should increase the signal-to-noise ratio. I
propose to achieve this by only logging API functions that cross the API
boundary. This is a divergence of what we had before, where a select
number of functions were logged, irregardless of the API boundary, a
concept that was introduced for the reproducers. However, I believe this
is in line with the purpose of the API log.

Differential revision: https://reviews.llvm.org/D60984

llvm-svn: 359016

Same as G_FCEIL, G_FABS, etc. Just move it into that rule.

Add a legalizer test for G_FMA, which we didn't have before and update
arm64-vfloatintrinsics.ll.

llvm-svn: 359015

Summary:
AAResults should not invalidate AAManager.
Update tests.

Reviewers: chandlerc

Subscribers: mehdi_amini, jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 359014

Noticed an unnecessary fallback in arm64-vmul caused by this.

Also add a regbankselect test for G_FMA.

llvm-svn: 359013

Without this patch, APSInt inherits APInt::isNegative, which merely
checks the sign bit without regard to whether the type is actually
signed.  isNonNegative and isStrictlyPositive call isNegative and so
are also affected.

This patch adjusts APSInt to override isNegative, isNonNegative, and
isStrictlyPositive with implementations that consider whether the type
is signed.

A large set of Clang OpenMP tests are affected.  Without this patch,
these tests assume that `true` is not a valid argument for clauses
like `collapse`.  Indeed, `true` fails APInt::isStrictlyPositive but
not APSInt::isStrictlyPositive.  This patch adjusts those tests to
assume `true` should be accepted.

This patch also adds tests revealing various other similar fixes due
to APSInt::isNegative calls in Clang's ExprConstant.cpp and
SemaExpr.cpp: `++` and `--` overflow in `constexpr`, evaluated object
size based on `alloc_size`, `<<` and `>>` shift count validation, and
OpenMP arra...

This was a speculative fix trying to placate some bots, but it's
ultimately just a bot configuration problem and not a code problem.

llvm-svn: 359011

This was meant to be part of the original commit r358921, but somehow
got lost.

<rdar://problem/49751748>

llvm-svn: 359010

llvm-svn: 359009

Must have picked up some transient code changes when originally generating this.

llvm-svn: 359008

Also add a test for demanling the co_await operator.

llvm-svn: 359007

llvm-svn: 359006

llvm-svn: 359005

llvm-svn: 359004

<rdar://problem/50117620>

llvm-svn: 359003

llvm-svn: 359002

<rdar://problem/50117620>

llvm-svn: 359001

If we have a masked.load from a location we know to be dereferenceable, we can simply issue a speculative unconditional load against that address. The key advantage is that it produces IR which is well understood by the optimizer. The select (cnd, load, passthrough) form produced should be pattern matchable back to hardware predication if profitable.

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

llvm-svn: 359000

Circling back to a leftover bit from PR39859:
https://bugs.llvm.org/show_bug.cgi?id=39859#c1

...we have this counter-intuitive (based on the test diffs) opportunity to use 'psubus'.
This appears to be the better perf option for both Haswell and Jaguar based on llvm-mca.
We already do this transform for the SETULT predicate, so this makes the code more
symmetrical too. If we have pminub/pminuw, we prefer those, so this should not affect
anything but pre-SSE4.1 subtargets.

  $ cat before.s
	movdqa	-16(%rip), %xmm2    ## xmm2 = [32768,32768,32768,32768,32768,32768,32768,32768]
	pxor	%xmm0, %xmm2
	pcmpgtw	-32(%rip), %xmm2 ## xmm2 = [255,255,255,255,255,255,255,255]
	pand	%xmm2, %xmm0
	pandn	%xmm1, %xmm2
	por	%xmm2, %xmm0

  $ cat after.s
	movdqa	-16(%rip), %xmm2    ## xmm2 = [256,256,256,256,256,256,256,256]
	psubusw	%xmm0, %xmm2
	pxor	%xmm3, %xmm3
	pcmpeqw	%xmm2, %xmm3
	pand	%xmm3, %xmm0
	pandn	%xmm1, %xmm3
	por	%xmm3, %xmm0

  $ llvm-mca before.s -mcpu=haswell
  Iterations:        100
  Instructions:      600
  Total Cycles:      909
  Total uOps:        700

  Dispatch Width:    4
  uOps Per Cycle:    0.77
  IPC:               0.66
  Block RThroughput: 1.8

  $ llvm-mca after.s -mcpu=haswell
  Iterations:        100
  Instructions:      700
  Total Cycles:      409
  Total uOps:        700

  Dispatch Width:    4
  uOps Per Cycle:    1.71
  IPC:               1.71
  Block RThroughput: 1.8

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

llvm-svn: 358999

64bit mode must use 64bit registers, otherwise assumptions about the top
half of the registers are made. Problem found by Takeshi Nakayama in
NetBSD.

llvm-svn: 358998

Regresses some apple_names situations - still investigating.

This reverts commit r358931.

llvm-svn: 358997

While touching the code, simplify if feasible.

llvm-svn: 358996

Runtime relocation are generated for relocations of type
R_WASM_MEMORY_ADDR_I32 when in PIC mode (either -shared or -pie).

Followup on https://reviews.llvm.org/D60882.

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

llvm-svn: 358995

This patch adds support for parsing and assembling the %tls_ie_pcrel_hi
and %tls_gd_pcrel_hi modifiers.

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

llvm-svn: 358994

llvm-svn: 358993

Essentially complete a proper rebase of the V3 metadata change over
https://reviews.llvm.org/D49096.

Minimize the diff between the V2 and V3 variants of the relevant lit
tests, and clean up some trailing whitespace.

llvm-svn: 358992

llvm-svn: 358991

dynamic-section-sh_size.elf was introduced in D25090.
Now it is possible to use yaml2obj instead. 
That is what this patch does.

Also I added one more case of a possibly broken .dynamic
section just in case.

llvm-svn: 358990