This patch integrates operand bundle llvm.assumes [0] with the
Attributor. Most IRAttributes will now look at uses of the associated
value and if there are llvm.assume operand bundle uses with the right
tag we will check if they are in the must-be-executed-context (around
the context instruction). Droppable users, which is currently only
llvm::assume, are handled special in some places now as well.

[0] http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html

Reviewed By: uenoku

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

This reverts commit 4a0267e3.

Summary:
The restriction that a derived attribute should represent an
attribute/be materializable as an attribute was not made clear.

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

Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.

---

lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).

Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.

Depends on D76336.

rdar://60307600

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

[X86] Disable autoupgrade support for avx512.mask.broadcasti32x2.* and avx512.mask.broadcastf32x2.*.

These intrinsics take a v4i32/v4f32 input and are supposed to
broadcast elements 0 and 1. Instead the autoupgrade code was
broadcasting elements 0, 1, 2, and 3.

I could fix the autoupgrade, but since its been broken for years
it seemed better just to steer anyone still trying to use it away
completely.

This fixes a miscompile when the parameter is actually underaligned.
rdar://58316406

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

Summary:
Currently we only log in debug builds but I don't see why we would do this as this is neither
expensive and seems useful.

I looked into the git history of this code and it seems originally there was also an assert here
and the logging here was the #else branch branch for non-Debug builds.

Reviewers: #lldb, labath

Reviewed By: labath

Subscribers: JDevlieghere

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

This reverts commit 6905394d. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:

http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio

/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
 // CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
                ^
<stdin>:3:2: note: scanning from here
 frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]

Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:

```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```

This just always increments those two counters independent of build mode.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

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

Summary:
Dumping the frame using the user-set format could cause that a debug LLDB doesn't behave as a release LLDB,
which could potentially break replaying a reproducer.

Also it's kinda strange that the frame format set by the user is used in the internal log output.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

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

Summary:
This revisions performs several cleanups to the generated dialect documentation:
* Standardizes format of attributes/operands/results sections
* Splits out operation/type/dialect documentation generation to allow for composing generated and hand-written documentation
* Add section for declarative assembly syntax and successors
* General cleanup

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

This reverts commit 4e0fe038. Re-lands
65b21282.

After landing 5ff5ddd0 to add int3 into
trailing unreachable blocks, we can now remove these extra stack
adjustments without confusing the Win64 unwinder. See
https://llvm.org/45064#c4 or X86AvoidTrailingCall.cpp for a full
explanation.

Fixes PR45064.

This allows creating custom test formats on top of `executeShTest` that
inject commands at the beginning of the file being parsed, without
requiring these commands to physically appear in the test file itself.

For example, one could define a test format that prints out additional
debug information at the beginning of each test. More realistically,
this has been used to define custom test formats like one that supports
compilation failure tests (e.g. with the extension `compile.fail.cpp`)
by injecting a command that calls the compiler on the file itself and
expects it to fail.

Without this change, the only alternative is to create a temporary file
with the same content as the original test, then prepend the desired
`// RUN:` lines to that file, and call `executeShTest` on that file
instead. This is both slow and cumbersome to do.

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

lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).

Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.

Depends on D76336.

rdar://60307600

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

Record the address of a tail-calling branch instruction within its call
site entry using DW_AT_call_pc. This allows a debugger to determine the
address to use when creating aritificial frames.

This creates an extra attribute + relocation at tail call sites, which
constitute 3-5% of all call sites in xnu/clang respectively.

rdar://60307600

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

Summary:
[libomptarget][nfc] Explicitly static function scope shared variables

`__shared__` in CUDA implies static in function scope. See e.g. D.2.1.1
in CUDA_C_Programming_Guide.pdf,
http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/

This is surprising for non-cuda developers, see e.g. D73239 where I thought
local variables would be thread local.

Tested by IR diff of libomptarget.bc (no change), running in tree tests,
and binary diff of the nvcc static archives (no significant change).

Reviewers: jdoerfert, ABataev, grokos

Reviewed By: jdoerfert

Subscribers: openmp-commits

Tags: #openmp

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

These result codes already exist, but they were not documented. I assume
this is an oversight when adding these result codes.

Summary:
DivRemPairs is unsound with respect to undef values.

```
      // bb1:
      //   %rem = srem %x, %y
      // bb2:
      //   %div = sdiv %x, %y
      // -->
      // bb1:
      //   %div = sdiv %x, %y
      //   %mul = mul %div, %y
      //   %rem = sub %x, %mul
```

If X can be undef, X should be frozen first.
For example, let's assume that Y = 1 & X = undef:
```
   %div = sdiv undef, 1 // %div = undef
   %rem = srem undef, 1 // %rem = 0
 =>
   %div = sdiv undef, 1 // %div = undef
   %mul = mul %div, 1   // %mul = undef
   %rem = sub %x, %mul  // %rem = undef - undef = undef
```
http://volta.cs.utah.edu:8080/z/m7Xrx5

Same for Y. If X = 1 and Y = (undef | 1), %rem in src is either 1 or 0,
but %rem in tgt can be one of many integer values.

This resolves https://bugs.llvm.org/show_bug.cgi?id=42619 .

This miscompilation disappears if undef value is removed, but it may take a while.
DivRemPair happens pretty late during the optimization pipeline, so this optimization seemed as a good candidate to fix without major regression using freeze than other broken optimizations.

Reviewers: spatel, lebedev.ri, george.burgess.iv

Reviewed By: spatel

Subscribers: wuzish, regehr, nlopes, nemanjai, hiraditya, llvm-commits

Tags: #llvm

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

Forget to squash into 2ea46051

These currently fail to form add3 due to the pointer type, but they
should be handle.

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

Summary:
This seems only useful for debugging and it's just plainly printf'ing to the console instead
of some log, so let's remove this.

Reviewers: #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: JDevlieghere

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

This reverts commit 129c911e.

Due to an internal benchmark regression.

Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.

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

This adds a simple fold to combine VMOVrh load to a integer load.
Similar to what is already performed for BITCAST, but needs to account
for the types being of different sizes, creating an zero extending load.

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

The current implementation collects all Preds/Succs of a Dep of kind Output, creating a long chain and subsequently a schedule with an unnecessarily large II.
Was this done on purpose for a reason I'm missing?

Reviewed By: bcahoon

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

rL368506 handled the basic case, but we need to account for boolean logic patterns as well.

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