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

Use the current getAlign() APIs where it makes sense, and use Align
instead of MaybeAlign when we know the value is non-zero.

This reverts commit 3185881d
and adds a missing "include(AddLLVM)" (similar lines already
exist elsewhere in compiler-rt).

We would return `LLDB_INVALID_IMAGE_TOKEN` for the address rather than
the correct value of `LLDB_IMAGE_ADDRESS`.  This would result in the
check for the return value to silently pass on x64 as the invalid
address and invalid token are of different sizes (`size_t` vs
`uintprr_t`).  This corrects the return value to `LLDB_INVALID_ADDRESS`
and addresses the rest to reset the mapped address to the invalid value.

This was found by inspection when trying to implement module support for
Windows.

Now that we have scalable vectors, there's a distinction that isn't
getting captured in the original SequentialType: some vectors don't have
a known element count, so counting the number of elements doesn't make
sense.

In some cases, there's a better way to express the commonality using
other methods. If we're dealing with GEPs, there's GEP methods; if we're
dealing with a ConstantDataSequential, we can query its element type
directly.

In the relatively few remaining cases, I just decided to write out
the type checks. We're talking about relatively few places, and I think
the abstraction doesn't really carry its weight. (See thread "[RFC]
Refactor class hierarchy of VectorType in the IR" on llvmdev.)

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

instead of recursing on the stack.

This doesn't actually resolve PR45333, because we now hit stack overflow
somewhere else, but it does get us further. I've not found any way of
testing this that doesn't still crash elsewhere.

PR: 45425
<rdar://problem/61359768>

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

Summary:
In lieu of a proper pass that strips debug info, add a way
to omit debug-locations from the MIR output so that
instructions with MMO's continue to match CHECK's when
mir-debugify is used

Reviewers: aprantl, bogner, vsk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary:
Thanks to Bill Wendling (void) for the report and steps to reproduce.  It looks
like this was missed during r350508's cleanup of the CallSite split into
CallBase, CallInst, and CallBrInst.

This was exposed by running pgo on a callbr, which was creating a ptrtoint to
the inline asm thinking it was an indirect call. The relevant callchain looks
like:

    IndirectCallPromotionPlugin::run()
    -> PGOIndirectCallVisitor::findIndirectCalls()
      -> PGOIndirectCallVisitor::visitCallBase()
        -> CallBase::isIndirectCall()

Reviewers: void, chandlerc

Reviewed By: void

Subscribers: hiraditya, llvm-commits, craig.topper, srhines

Tags: #llvm

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

Add LLDB_REGISTER_METHOD macros for GetRetriesWithFixIts and
SetRetriesWithFixIts.

The rewriter generates a call to build that is not handled by opdef generator
and so will fail to compile. Also if this is a root node being replaced
(depth 0) then using the more generic build method in the rewrite suffices.

Summary:
In some cases, ASan may insert instrumentation before function arguments
have been stored into their allocas. This causes two issues:

1) The argument value must be spilled until it can be stored into the
   reserved alloca, wasting a stack slot.

2) Until the store occurs in a later basic block, the debug location
   will point to the wrong frame offset, and backtraces will show an
   uninitialized value.

The proposed solution is to move instructions which initialize allocas
for arguments up into the entry block, before the position where ASan
starts inserting its instrumentation.

For the motivating test case, before the patch we see:

```
 | 0033: movq %rdi, 0x68(%rbx)  |   | DW_TAG_formal_parameter     |
 | ...                          |   |   DW_AT_name ("a")          |
 | 00d1: movq 0x68(%rbx), %rsi  |   |   DW_AT_location (RBX+0x90) |
 | 00d5: movq %rsi, 0x90(%rbx)  |   |       ^ not correct ...     |
```

and after the patch we see:

```
 | 002f: movq %rdi, 0x70(%rbx)  |   | DW_TAG_formal_parameter     |
 |                              |   |   DW_AT_name ("a")          |
 |                              |   |   DW_AT_location (RBX+0x70) |
```

rdar://61122691

Reviewers: aprantl, eugenis

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.

The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.

For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.

rdar://problem/60640017

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

Both test formats are equivalent, so this *should* not be a problem.
We've fixed a couple of failures uncovered by the first time we tried
making the switch, so this new attempt should go even farther.

If failures are noticed, it should be fine to revert this commit, but
please give a heads up afterwards so we know to address the issues!

Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.

Add support and update testcases.

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

Summary:
To debugify MIR, we need to be able to create metadata and to do that, we
need a non-const Module. However, MachineFunction only had a const reference
to the Function preventing this.

Reviewers: aprantl, bogner

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary:
It can be helpful to test behaviour w.r.t locations without having DEBUG_VALUE
around. In particular, because DEBUG_VALUE has the potential to change CodeGen
behaviour (e.g. hasOneUse() vs hasOneNonDbgUse()) while locations generally
don't.

Reviewers: aprantl, bogner

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This reverts commit 6c1a9fb1.

Commit causes failures:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/49206

This test is currently XFAILed but is passing on the Windows bot.

X86ISelLowering: Minor refactor to avoid redundant initialization while ensuring compiler warnings can hopefully still prove initialization

Based on post-commit review/discussion in fabe52a7412b

Summary:
While [the original diff](https://reviews.llvm.org/D42493) makes a lot of sense, and multiple inline block parameter/trailing paramemter after inline block paramemter should be discouraged, the formatting result is different than what xcode does by default
For the exact same example provided in the original diff:
```
[object
  blockArgument:^{
    a = 42;
  }
     anotherArg:42];
```
The code is hard to read and not very visually pleasing

This diff uses `ObjCBreakBeforeNestedBlockParam` to shield from the formatting
When it's set to false, don't allign the inline block paramemters.

Reviewers: jolesiak, benhamilton, jinlin

Reviewed By: jolesiak

Subscribers: cfe-commits

Tags: #clang

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

Greg Clayton a few years ago.

My patch to augment the symbol table in Mach-O files with the
dyld trie exports data structure only categorized symbols as code
or data, but Greg Clayton had a patch to do something similar to
swift a few years ago that had a more extensive categorization of
symbols, as well as extracting some objc class/ivar names from the
entries. This patch is basically just Greg's, updated a bit and
with a test case added to it.

<rdar://problem/50791451>

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

Reviewers: sameerds, dstuttard

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

Summary:
This patch moves the forward declarations of command-line `cl::*`
externs in `MachODump.cpp` and `llvm-objdump.cpp` into the headers
corresponding to the file that defines the variable. At the same time,
these externs are moved into the `llvm::objdump` namespace. The externs
that are not referenced outside their defining translation unit are made
static.

This does not factor out uses of the Mach-O options from
`llvm-objdump.cpp`.

Reviewers: jhenderson, MaskRay, DiggerLin, jasonliu, daltenty

Reviewed By: jhenderson, MaskRay

Subscribers: rupprecht, llvm-commits

Tags: #llvm

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

A global symbol that is defined in a comdat should not generate an alias since
call sites that would've referred to that symbol will refer to their own
independent local aliases rather than the surviving global comdat one. This
could result in something that looks like:

```
ld.lld: error: relocation refers to a discarded section: .text._ZN3fbl8internal18NullFunctionTargetIvJjjPjEED1Ev.stub
>>> defined in user-x64-clang/obj/system/ulib/minfs/libminfs.a(minfs._sources.file.cc.o)
>>> section group signature: _ZN3fbl8internal18NullFunctionTargetIvJjjPjEED1Ev.stub
>>> prevailing definition is in user-x64-clang/obj/system/ulib/minfs/libminfs.a(minfs._sources.vnode.cc.o)
>>> referenced by function.h:169 (../../zircon/system/ulib/fbl/include/fbl/function.h:169)
>>>               minfs._sources.file.cc.o:(minfs::File::AllocateAndCommitData(std::__2::unique_ptr<minfs::Transaction, std::__2::default_delete<minfs::Transaction> >)) in archive user-x64-clang/obj/system/ulib/minfs/libminfs.a
```

We ran into this when experimenting with a new C++ ABI for fuchsia
(refer to D72959) which takes relative offsets between comdat'd functions
which is why the normal C++ user wouldn't run into this.

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

No intended behavior change.

Summary:
A bug report mentioned that LLVM was producing jumps off the end of a
function when using "asm goto with outputs". Further digging pointed to
MachineBasicBlocks that had their address taken and were indirect
targets of INLINEASM_BR being removed by BranchFolder, because their
 predecessor list was empty, so they appeared to have no entry.

This was a cascading failure caused earlier, during Pre-RA instruction
scheduling. We have a few special cases in Pre-RA instruction scheduling
where we split a MachineBasicBlock in two.  This requires careful
handing of predecessor and successor lists for a MachineBasicBlock that
was split, and careful handing of PHI MachineInstrs that referred to the
MachineBasicBlock before it was split.

The clue that led to this fix was the observation that many callers of
MachineBasicBlock::splice() frequently call
MachineBasicBlock::transferSuccessorsAndUpdatePHIs() to update their PHI
nodes after a splice. We don't want to reuse that method, as we have
custom successor transferring logic for this block split.

This patch fixes 2 pre-existing bugs, and adds tests.

The first bug was that MachineBasicBlock::splice() correctly handles
updating most successors and predecessors; we don't need to do anything
more than removing the previous fallthrough block from the first half of
the split block post splice. Previously, we were updating the successor
list incorrectly (updating successors updates predecessors).

The second bug was that PHI nodes that needed registers from the first
half of the split block were not having entries populated.  The register
live out information was correct, and the FuncInfo->PHINodesToUpdate was
correct. Specifically, the check in SelectionDAGISel::FinishBasicBlock:

    for (unsigned i = 0, e = FuncInfo->PHINodesToUpdate.size(); i != e; ++i) {
      MachineInstrBuilder PHI(*MF, FuncInfo->PHINodesToUpdate[i].first);
      if (!FuncInfo->MBB->isSuccessor(PHI->getParent()))
        continue;
      PHI.addReg(FuncInfo->PHINodesToUpdate[i].second).addMBB(FuncInfo->MBB);

was `continue`ing because FuncInfo->MBB tracks the second half of
the post-split block; no one was updating PHI entries for the first half
of the post-split block.

SelectionDAGBuilder::UpdateSplitBlock() already expects to perform
special handling for MachineBasicBlocks that were split post calls to
ScheduleDAGSDNodes::EmitSchedule(), so I'm confident that it's both
correct for ScheduleDAGSDNodes::EmitSchedule() to return the second half
of the split block `CopyBB` which updates `FuncInfo->MBB` (ie. the
current MachineBasicBlock being processed), and perform special handling
for this in SelectionDAGBuilder::UpdateSplitBlock().

Reviewers: void, craig.topper, efriedma

Reviewed By: void, efriedma

Subscribers: hfinkel, fhahn, MatzeB, efriedma, hiraditya, llvm-commits, srhines

Tags: #llvm

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

Summary:
This is a patch that Android has been carrying in its tree for several
years. This patch upstreams the existing ABI.

There's some historical cruft here. __regex_word used to be a part of
regex_traits rather than ctype_base. Bionic also used to use its own
ctype implementation because the libc++ builtin one wasn't available
yet. Bionic's ctype masks were 8 bits wide and already saturated, so a
wider type needed to be used for the regex mask, and the existing
value was already used so Android needed to specify its own.

Since then Android has migrated to the builtin ctype implementation
and this patch probably should have been dropped then. Unfortunately
that was not noticed at the time, so now we need to keep this to
maintain the current ABI.

Reviewers: EricWF, #libc, ldionne

Reviewed By: #libc, ldionne

Subscribers: dexonsmith, ldionne, libcxx-commits

Tags: #libc

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

Reviewers: ldionne, #libunwind, mstorsjo

Reviewed By: ldionne, #libunwind, mstorsjo

Subscribers: mstorsjo, dexonsmith, llvm-commits, libcxx-commits

Tags: #llvm, #libunwind

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

The extracts from control flow intrinsics are already properly handled
by divergence analysis. The inline asm case isn't dead, but has also
never really worked correctly so leave it as-is for now.

Zero sized bit-fields aren't included in the CGRecordLayout, so we shouldn't be
calling EmitLValueForField for them. rdar://60695105

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