[clang][DependencyFileGenerator] Fix missing -MT option handling

Targets in DependencyFileGenerator don't necessarily come from -MT option.

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

llvm-svn: 371279

Fix thunks.cpp test, don't FileCheck for anon namespace id

The anon namespace id is a hash of the main input path to the compiler,
which varies in the test suite because the input path is absolute.

llvm-svn: 371277

[Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership
qualifications as unavailable if the union is declared in a system
header

r365985 stopped marking those fields as unavailable, which caused the
union's NonTrivialToPrimitive* bits to be set to true. This patch
restores the behavior prior to r365985, except that users can explicitly
specify the ownership qualification of the field to instruct the
compiler not to mark it as unavailable.

rdar://problem/53420753

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

llvm-svn: 371276

[Sema] Diagnose default-initialization, destruction, and copying of
non-trivial C union types

This recommits r365985, which was reverted because it broke a few
projects using unions containing non-trivial ObjC pointer fields in
system headers. We now have a patch to fix the problem (see
https://reviews.llvm.org/D65256).

Original commit message:

This patch diagnoses uses of non-trivial C unions and structs/unions
containing non-trivial C unions in the following contexts, which require
default-initialization, destruction, or copying of the union objects,
instead of disallowing fields of non-trivial types in C unions, which is
what we currently do:

- function parameters.
- function returns.
- assignments.
- compound literals.
- block captures except capturing of `__block` variables by non-escaping blocks.
- local and global variable definitions.
- lvalue-to-rvalue conversions of volatile types.

See the discussion in https://reviews.llvm.org/D62988 for more background.

rdar://problem/50679094

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

llvm-svn: 371275

Synchronize LLVM's copy of libc++abi's demangler with the libc++abi
version after r371273.

Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the demangler.

llvm-svn: 371274

Implement demangling support for C++20 lambda expression extensions.

This implements demangling support for the mangling extensions specified
in https://github.com/itanium-cxx-abi/cxx-abi/pull/85, much of which is
implemented in Clang r359967 and r371004.

Specifically, this provides demangling for:

 * <template-param-decl> in <lambda-sig>
 * <template-param> with non-zero level
 * lambda-expression literals (not emitted by Clang yet)
 * nullptr literals
 * string literals

(The final two seem unrelated, but handling them was necessary in order
to disambiguate between lambda expressions and the other forms of
literal for which we have a type but no value.)

When demangling a <lambda-sig>, we form template parameters with no
corresponding argument, so we cannot substitute in the argument in the
demangling. Instead we invent synthetic names for the template
parameters (eg, '[]<typename $T>($T *x)').

llvm-svn: 371273

Use musttail for variadic method thunks when possible

This avoids cloning variadic virtual methods when the target supports
musttail and the return type is not covariant. I think we never
implemented this previously because it doesn't handle the covariant
case. But, in the MS ABI, there are some cases where vtable thunks must
be emitted even when the variadic method defintion is not available, so
it looks like we need to implement this. Do it for both ABIs, since it's
a nice size improvement and simplification for Itanium.

Emit an error when emitting thunks for variadic methods with a covariant
return type. This case is essentially not implementable unless the ABI
provides a way to perfectly forward variadic arguments without a tail
call.

Fixes PR43173.

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

llvm-svn: 371269

Update lld tests dynamic-list.s and symbol-override.s to use llvm-nm

The following tests failed on Windows bots due to nm not being
available:

  lld/test/ELF/dynamic-list.s
  lld/test/ELF/symbol-override.s

llvm-svn: 371267

[AArch64][GlobalISel] Enable the localizer for optimized builds.

Despite the fact that the localizer's original motivation was to fix horrendous
constant spilling at -O0, shortening live ranges still has net benefits even
with optimizations enabled.

On an -Os build of CTMark, doing this improves code size by 0.5% geomean.

There are a few regressions, bullet increasing in size by 0.5%. One example from
bullet where code size increased slightly was due to GlobalISel actually now
generating the same code as SelectionDAG. So we actually have an opportunity
in future to implement better heuristics for localization and therefore be
*better* than SDAG in some cases. In relation to other optimizations though that
one is relatively minor.

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

llvm-svn: 371266

[InstCombine] Refactor substitution of instruction in the parent BB (NFC)

Add the new method `LibCallSimplifier::substituteInParent()` that calls
`LibCallSimplifier::replaceAllUsesWith()' and
`LibCallSimplifier::eraseFromParent()` back to back, simplifying the
resulting code.

llvm-svn: 371264

[ORC][RPC] Join server thread before checking condition in unit test.

Otherwise we have a race on the sent-messages count.

llvm-svn: 371263

[IR] CallBrInst: scan+update arg list when indirect dest list changes

Summary:
There's an unspoken invariant of callbr that the list of BlockAddress
Constants in the "function args" list match the BasicBlocks in the
"other labels" list. (This invariant is being added to the LangRef in
https://reviews.llvm.org/D67196).

When modifying the any of the indirect destinations of a callbr
instruction (possible jump targets), we need to update the function
arguments if the argument is a BlockAddress whose BasicBlock refers to
the indirect destination BasicBlock being replaced.  Otherwise, many
transforms that modify successors will end up violating that invariant.
A recent change to the arm64 Linux kernel exposed this bug, which
prevents the kernel from booting.

I considered maintaining a mapping from indirect destination BasicBlock
to argument operand BlockAddress, but this ends up being a one to
potentially many (though usually one) mapping.  Also, the list of
arguments to a function (or more typically inline assembly) ends up
being less than 10.  The implementation is significantly simpler to just
rescan the full list of arguments. Because of the one to potentially
many relationship, the full arg list must be scanned (we can't stop at
the first instance).

Thanks to the following folks that reported the issue and helped debug
it:
* Nathan Chancellor
* Will Deacon
* Andrew Murray
* Craig Topper

Link: https://bugs.llvm.org/show_bug.cgi?id=43222
Link: https://github.com/ClangBuiltLinux/linux/issues/649
Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html
Reviewers: craig.topper, chandlerc

Reviewed By: craig.topper

Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines

Tags: #llvm

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

llvm-svn: 371262

[X86] Add a AVX512VBMI command line to min-legal-vector-width.ll. Always enable fast-variable-shuffle

Trying to minimize the features we need to manipulate when this
is updated for D67259.

The VBMI is interesting because it enables some improved combining
for truncates.

I enabled fast-variable-shuffle because all the CPUs we're going
to add implicitly enable it. So they can share check lines.

llvm-svn: 371261

[X86] Replace -mcpu with -mattr on some tests.

llvm-svn: 371260

[test] Add a FIXME test for stop-command-source-on-error

Modifying the interpreter settings is tricky because they don't take
effect until we create a new command interpreter, which should be merely
an implementation detail. This leads to confusing and unexpected
scenarios.

This adds a test cases with FIXMEs for some of the odd scenarios I
encountered. I didn't XFAIL the test because I don't think there's a way
to get an unexpected PASS if any of the commands succeeds and splitting
up the file in multiple tests seems excessive.

llvm-svn: 371259

[Core] Remove use of ClangASTContext in DumpDataExtractor

Summary:
DumpDataExtractor uses ClangASTContext in order to get the proper llvm
fltSemantics for the type it needs so that it can dump floats in a more
precise way. However, there's no reason that this behavior needs to be
specific ClangASTContext. Instead, I think it makes sense to ask
TypeSystems for the float semantics for a type of a given size.

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

llvm-svn: 371258

[analyzer] Add minimal support for fix-it hints.

Allow attaching fixit hints to Static Analyzer BugReports.

Fixits are attached either to the bug report itself or to its notes
(path-sensitive event notes or path-insensitive extra notes).

Add support for fixits in text output (including the default text output that
goes without notes, as long as the fixit "belongs" to the warning).

Add support for fixits in the plist output mode.

Implement a fixit for the path-insensitive DeadStores checker. Only dead
initialization warning is currently covered.

Implement a fixit for the path-sensitive VirtualCall checker when the virtual
method is not pure virtual (in this case the "fix" is to suppress the warning
by qualifying the call).

Both fixits are under an off-by-default flag for now, because they
require more careful testing.

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

llvm-svn: 371257

[analyzer] pr43179: Make CallDescription defensive against C variadic functions.

Most functions that our checkers react upon are not C-style variadic functions,
and therefore they have as many actual arguments as they have formal parameters.

However, it's not impossible to define a variadic function with the same name.
This will crash any checker that relies on CallDescription to check the number
of arguments but silently assumes that the number of parameters is the same.

Change CallDescription to check both the number of arguments and the number of
parameters by default.

If we're intentionally trying to match variadic functions, allow specifying
arguments and parameters separately (possibly omitting any of them).
For now we only have one CallDescription which would make use of those,
namely __builtin_va_start itself.

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

llvm-svn: 371256

[ORC] Add a missing #include atomic.

Hopefully this will fix the bot build failures from r371245.

llvm-svn: 371255

GlobalISel: Add G_FMAD instruction

llvm-svn: 371254

GlobalISel: Support physical register inputs in patterns

llvm-svn: 371253

Update comment for <template-param-decl> mangling to match extended mangling rule in r371004.

llvm-svn: 371252

Remove dead .seh_stackalloc parsing method in X86AsmParser

The shared COFF asm parser code handles this directive, since it is
shared with AArch64. Spotted by Alexandre Ganea in review.

llvm-svn: 371251

[clang][Index][NFC] Put IndexingOptions to a separate header

llvm-svn: 371250

AMDGPU: Fix typo

llvm-svn: 371249

[llvm-ifs] Improving detection of PlatformKind from triple for TBD generation.

It was pointed out that I had hard-coded PlatformKind. This is rectifying that.

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

llvm-svn: 371248

[PowerPC][XCOFF] Remove basic test. [NFC]

Test verified that we could compile an empty module and produce an XCOFF
object file. Newer tests superssed this coverage, its safe to remove.

llvm-svn: 371247

[ConstantFolding] Add new test cases for transcendentals (NFC)

llvm-svn: 371246

[ORC] Make sure RPC channel-send is called in blocking calls and responses.

ORC-RPC batches calls by default, and the channel's send method must be called
to transfer any buffered calls to the remote. The call to send was missing on
responses and blocking calls in the SingleThreadedRPCEndpoint. This patch adds
the necessary calls and modifies the RPC unit test to check for them.

llvm-svn: 371245

[llvm-jitlink] Add optional slab allocator for testing locality optimizations.

The llvm-jitlink utility now accepts a '-slab-allocate <size>' option. If given,
llvm-jitlink will use a slab-based memory manager rather than the default
InProcessMemoryManager. Using a slab allocator will allow reliable testing of
future locality based optimizations (e.g. PLT and GOT elimination) in JITLink.

The <size> argument is a number, optionally followed by a units specifier (Kb,
Mb, or Gb). If the units are not given then the number is assumed to be in Kb.

llvm-svn: 371244

[X86] Use MOVSX by default instead of CBW to extend i8 to AX for i8 sdivrem.

We can use a MOVSX16 here then rely on FixupBWInst to change to
MOVSX32 if the upper bits are dead. With a special case to
not promote if it could be turned into CBW.

Then we can rely on X86MCInstLower to turn the MOVSX into CBW
very late if register allocation worked out.

Using MOVSX gives an opportunity to use the MOVSX as a both a
copy and a sign extend since the input and output register aren't
tied together.

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

llvm-svn: 371243

[X86] Use MOVZX16rr8/MOVZXrm8 when extending input for i8 udivrem.

We can rely on X86FixupBWInsts to turn these into MOVZX32. This
simplifies a follow up commit to use MOVSX for i8 sdivrem with
a late optimization to use CBW when register allocation works out.

llvm-svn: 371242

[LifetimeAnalysis] don't use raw string literals in macros

They broke the AArch64 bots (gcc does not support it)

llvm-svn: 371241

[X86] Teach FixupBWInsts to turn MOVSX16rr8/MOVZX16rr8/MOVSX16rm8/MOVZX16rm8 into their 32-bit dest equivalents when the upper part of the register is dead.

llvm-svn: 371240

[PowerPC][XCOFF] Verify symbol table in xcoff object files. [NFC]

Extend the common/local-common testing for object files to also verify the
symbol table now that the needed functionality has landed in llvm-readobj.

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

llvm-svn: 371237

[ConstantFolding] Refactor functions not available before C99 (NFC)

Note the cases when calling a function at compile time may fail if the host
does not support the C99 run time library.

llvm-svn: 371236

[FPEnv] Teach the IRBuilder about constrained FPToSI and FPToUI.

The IRBuilder doesn't know that the two floating point to integer instructions
have constrained equivalents. This patch adds the support by building on
the strict FP mode now present in the IRBuilder.

Reviewed by: John McCall
Approved by: John McCall
Differential Revision: https://reviews.llvm.org/D67291

llvm-svn: 371235

[lldb] Small optimization of FormatMap::Delete and FormatMap::Get

llvm-svn: 371234

[Remarks] Add support for internalizing a remark in a string table

In order to keep remarks around, we need to make them tied to a string
table.

Users then can delete the parser and rely on the string table to keep
the memory of the strings alive and deduplicated.

llvm-svn: 371233

[ARM] Add patterns for VSUB with q and r registers

Added patterns for VSUB to support q and r registers, which reduces
pressure on q registers.

llvm-svn: 371231

[ARM] Add patterns for VADD with q and r registers

Added support for VADD to use q and r registers, which reduces pressure
on q registers.

llvm-svn: 371230

[ARM] Add patterns for VMUL with q and r registers

Added support for VMUL to use an r register, this reduces pressure on
the q registers.

llvm-svn: 371229

[ConstantFolding] Refactor function match for better speed (NFC)

Use an `enum` instead of string comparison to match the candidate function.

llvm-svn: 371228

[AArch64][GlobalISel] Always fall back on tail calls with -tailcallopt

-tailcallopt requires that we perform different stack adjustments than with
sibling calls. For example, the `@caller_to0_from8` function in
test/CodeGen/AArch64/tail-call.ll requires that we adjust SP. Without
-tailcallopt, this adjustment does not happen. With it, however, it is expected.

So, to ensure that adding sibling call support doesn't break -tailcallopt,
make CallLowering always fall back on possible tail calls when -tailcallopt
is passed in.

Update test/CodeGen/AArch64/tail-call.ll with a GlobalISel line to make sure
that we don't differ from the SDAG implementation at any point.

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

llvm-svn: 371227

[NFCI] Unbreak buildbots

llvm-svn: 371226

[ELF] Replace error() with errorOrWarn() for the ASSERT command

Summary:
ld.bfd produces an output with --noinhibit-exec when an ASSERT fails.
Use errorOrWarn() so that we can produce an output as well.

An interesting case is that symbol assignments may execute multiple
times, so we probably want to suppress errors for non-final runs.

Reviewed By: peter.smith

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

llvm-svn: 371225

[InstCombine] pow(x, +/- 0.0) -> 1.0

Summary:
This isn't an important optimization at all... We're already doing:
  pow(x, 0.0) -> 1.0
My patch merely teaches instcombine that -0.0 does the same.

However, doing this fixes an AMAZING bug! Compile this program:

  extern "C" double pow(double, double);
  double boom(double base) {
    return pow(base, -0.0);
  }

With:
  clang++ ~/Desktop/fast-math.cpp -ffast-math -O2 -S

And clang will crash with a signal. Wow, fast math is so fast it ICEs the
compiler! Arguably, the generated math is infinitely fast.

What's actually happening is that we recurse infinitely in getPow. In debug we
hit its assertion:
  assert(Exp != 0 && "Incorrect exponent 0 not handled");

We avoid this entire mess if we instead recognize that an exponent of positive
and negative zero yield 1.0.

A separate commit, r371221, fixed the same problem. This only contains the added
tests.

<rdar://problem/54598300>

Reviewers: scanon

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

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

llvm-svn: 371224

[NFC] Added new tests for r371222

llvm-svn: 371223

[Diagnostics] Refactor code for -Wsizeof-pointer-div, catch more cases; also add -Wsizeof-array-div

Previously, -Wsizeof-pointer-div failed to catch:
const int *r;
sizeof(r) / sizeof(int);

Now fixed.
Also introduced -Wsizeof-array-div which catches bugs like:
sizeof(r) / sizeof(short);

(Array element type does not match type of sizeof operand).

llvm-svn: 371222

[SimplifyLibCalls] handle pow(x,-0.0) before it can assert (PR43233)

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

llvm-svn: 371221

[ARM] Sink add/mul(shufflevector(insertelement())) for MVE instruction selection

This patch sinks add/mul(shufflevector(insertelement())) into the basic block in which they are used so that they can then be selected together.

This is useful for various MVE instructions, such as vmla and others that take R registers.

Loop tests have been added to the vmla test file to make sure vmlas are generated in loops.

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

llvm-svn: 371218

Reland D66717 [ELF] Do not ICF two sections with different output sections (by SECTIONS commands)

Recommit r370635 (reverted by r371202), with one change: move addOrphanSections() before ICF.

Before, orphan sections in two different partitions may be folded and
moved to the main partition.

Now, InputSection->OutputSection assignment for orphans happens before
ICF. ICF does not fold input sections with different output sections.

With the PR43241 reproduce,
`llvm-objcopy --extract-partition libvr.so libchrome__combined.so libvr.so` => no error

Updated description:

Fixes PR39418. Complements D47241 (the non-linker-script case).

processSectionCommands() assigns input sections to output sections.
ICF is called before it, so .text.foo and .text.bar may be folded even if
their output sections are made different by SECTIONS commands.

```
markLive<ELFT>()
doIcf<ELFT>()                      // During ICF, we don't know the output sections
writeResult()
  combineEhSections<ELFT>()
  script->processSectionCommands() // InputSection -> OutputSection assignment
```

This patch splits processSectionCommands() into processSectionCommands()
and processSymbolAssignments(), and moves
processSectionCommands()/addOrphanSections() before ICF:

```
markLive<ELFT>()
combineEhSections<ELFT>()
script->processSectionCommands()
script->addOrphanSections();
doIcf<ELFT>()                      // should remove folded input sections
writeResult()
  script->processSymbolAssignments()
```

An alternative approach is to unfold a section `sec` in
processSectionCommands() when we find `sec` and `sec->repl` belong to
different output sections. I feel this patch is superior because this
can fold more sections and the decouple of
SectionCommand/SymbolAssignment gives flexibility:

* An ExprValue can't be evaluated before its section is assigned to an
  output section -> we can delete getOutputSectionVA and simplify
  another place where we had to check if the output section is null.
  Moreover, a case in linkerscript/early-assign-symbol.s can be handled
  now.
* processSectionCommands/processSymbolAssignments can be freely moved
  around.

llvm-svn: 371216

Revert "Revert r370635, it caused PR43241."

This reverts commit 50d2dca22b3b05d0ee4883b0cbf93d7d15f241fc.

llvm-svn: 371215

[AMDGPU] Enable constant offset promotion to immediate operand for VMEM stores

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

llvm-svn: 371214

[ELF][test] Simplify and reorganize tests

Add file-level comments
Delete insignificant addresses to make them more tolerant to layout changes
Simplify test output
Delete simple Inputs/*.s files

Delete version-script-copy-rel.s - covered by verdef-defaultver.s
Delete version-wildcard.test - covered by version-script-glob.s

llvm-svn: 371213

[Alignment][NFC] Use Align with TargetLowering::setPrefFunctionAlignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: nemanjai, javed.absar, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, s.egerton, pzheng, ychen, llvm-commits

Tags: #llvm

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

llvm-svn: 371212

[Object] remove struct constructor, NFC

Summary: make POD struct by removing ctors

Reviewers: avl, dblaikie

Reviewed By: dblaikie

Subscribers: ributzka, llvm-commits

Tags: #llvm

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

llvm-svn: 371211

[Alignment][NFC] Use Align with TargetLowering::setPrefLoopAlignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: nemanjai, hiraditya, kbarton, MaskRay, jsji, ychen, llvm-commits

Tags: #llvm

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

llvm-svn: 371210

[NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): pass a vector to EmitCheck()

Will be easier to add a new 'check' in a follow-up.

This was originally part of https://reviews.llvm.org/D67122

llvm-svn: 371208

[NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): refactor EmitGEPOffsetInBytes() helper

It shouldn't really be inlined into the EmitCheckedInBoundsGEP().
Refactoring it beforehand will make follow-up changes more obvious.

This was originally part of https://reviews.llvm.org/D67122

llvm-svn: 371207

[NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): add some comments to pointer-overflow check

It's rather eye-twiching, some comments may help here..

This was originally part of https://reviews.llvm.org/D67122

llvm-svn: 371206

libclang depends on ClangDriverOptions since r352803

Without this, the build would sometimes fail with

    In file included from clang/tools/libclang/CIndexer.cpp:17:
    In file included from clang/include/clang/Driver/Driver.h:15:
    clang/include/clang/Driver/Options.h:44:10: fatal error:
        'clang/Driver/Options.inc' file not found
    #include "clang/Driver/Options.inc"
             ^~~~~~~~~~~~~~~~~

if Options.inc wasn't generated before libclang was built
by coincidence.

(In the GN build, this works because lib/Driver there declares
the dep on tablegen as a public_dep since the generated file
is part of Driver's public interface, and then things work out
automatically without every client of Driver having to be careful.)

llvm-svn: 371205

[Alignment] fix dubious min function alignment

Summary:
This was discovered while introducing the llvm::Align type.
The original setMinFunctionAlignment used to take alignment as log2, looking at the comment it seems like instructions are to be 2-bytes aligned and not 4-bytes aligned.

Reviewers: uweigand

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371204

Revert r370635, it caused PR43241.

llvm-svn: 371202

[llvm-readelf] - Print unknown st_other value if present in GNU output.

This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40785.

llvm-readelf does not print the st_value of the symbol when
st_value has any non-visibility bits set.

This patch:

* Aligns "Ndx" row for the default and a new cases.
(it was 1 space character off for the case when "PROTECTED" visibility was printed)

* Prints "[<other>: 0x??]" for symbols which has an additional st_other bits set.
In compare with GNU, this logic is a bit simpler and seems to be more consistent.

For MIPS GNU can print named flags, though can't print a mix of them:
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE GLOBAL DEFAULT [OPTIONAL] UND a1
2: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS PLT] UND a2
3: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS PIC] UND a3
4: 00000000 0 NOTYPE GLOBAL DEFAULT [MICROMIPS] UND a4
5: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS16] UND a5
6: 00000000 0 NOTYPE GLOBAL DEFAULT [<other>: c] UND b1
7: 00000000 0 NOTYPE GLOBAL DEFAULT [<other>: 28] UND b2

On PPC64 it can print a localentry value that is encoded in the high bits of st_other
63: 0000000000000850 208 FUNC GLOBAL DEFAULT [<localentry>: 8] 12

We chose to print the raw st_other field, prefixed with '0x'.

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

llvm-svn: 371201

[Alignment][NFC] Use Align with TargetLowering::setMinFunctionAlignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jyknight, sdardis, nemanjai, javed.absar, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, s.egerton, pzheng, llvm-commits

Tags: #llvm

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

llvm-svn: 371200

[test] Update the name of the debug entry values option. NFC

llvm-svn: 371199

[DFAPacketizer] Track resources for packetized instructions

This patch allows the DFAPacketizer to be queried after a packet is formed to work out which
resources were allocated to the packetized instructions.

This is particularly important for targets that do their own bundle packing - it's not
sufficient to know simply that instructions can share a packet; which slots are used is
also required for encoding.

This extends the emitter to emit a side-table containing resource usage diffs for each
state transition. The packetizer maintains a set of all possible resource states in its
current state. After packetization is complete, all remaining resource states are
possible packetization strategies.

The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default
(most uses of the packetizer like MachinePipeliner don't care and don't need the extra
maintained state).

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

llvm-svn: 371198

Remove call to obsolete gethostbyname, using getaddrinfo

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

llvm-svn: 371195

[clangd] Use override keyword to override the base class method, NFC

llvm-svn: 371194

[DebugInfo] LiveDebugValues: explicitly terminate overwritten stack locations

If a stack spill location is overwritten by another spill instruction,
any variable locations pointing at that slot should be terminated. We
cannot rely on spills always being restored to registers or variable
locations being moved by a DBG_VALUE: the register allocator is entitled
to spill a value and then forget about it when it goes out of liveness.

To address this, scan for memory writes to spill locations, even those we
don't consider to be normal "spills". isSpillInstruction and
isLocationSpill distinguish the two now. After identifying spill
overwrites, terminate the open range, and insert a $noreg DBG_VALUE for
that variable.

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

llvm-svn: 371193

[AMDGPU] Mark s_barrier as having side effects but not accessing memory.

Summary:
This fixes poor scheduling in a function containing a barrier and a few
load instructions.

Without this fix, ScheduleDAGInstrs::buildSchedGraph adds an artificial
edge in the dependency graph from the barrier instruction to the exit
node representing live-out latency, with a latency of about 500 cycles.
Because of this it thinks the critical path through the graph also has
a latency of about 500 cycles. And because of that it does not think
that any of the load instructions are on the critical path, so it
schedules them with no regard for their (80 cycle) latency, which gives
poor results.

Reviewers: arsenm, dstuttard, tpr, nhaehnle

Subscribers: kzhuravl, jvesely, wdng, yaxunl, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371192

gn build: Merge r371182

llvm-svn: 371191

gn build: Merge r371179

llvm-svn: 371190

[ELF][test] Update test after r371185

llvm-svn: 371189

[ARM] Fix for buildbot

llvm-svn: 371187

[yaml2obj] Rename SHOffset (e_shoff) field to SHOff. NFC

`struct Elf*_Shdr` has a field `sh_offset`, named `ShOffset` in
llvm::ELFYAML::Section. Rename SHOffset (e_shoff) to SHOff to prevent confusion.

Reviewed By: grimar

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

llvm-svn: 371185

Reland [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics.

Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)

inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).

and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).

We now add the attributes to all redeclarations to fix thos issues and make their usage easier.

Reviewers: gribozavr

Subscribers: Szelethus, xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 371182

[lldb][NFC] Remove Args::StripSpaces

This just reimplemented llvm::StringRef::[r/l]trim().

llvm-svn: 371181

[lldb][NFC] Extend ArgsTest

llvm-svn: 371180

[ARM] MVE Tail Predication

The MVE and LOB extensions of Armv8.1m can be combined to enable
'tail predication' which removes the need for a scalar remainder
loop after vectorization. Lane predication is performed implicitly
via a system register. The effects of predication is described in
Section B5.6.3 of the Armv8.1-m Arch Reference Manual, the key points
being:
- For vector operations that perform reduction across the vector and
  produce a scalar result, whether the value is accumulated or not.
- For non-load instructions, the predicate flags determine if the
  destination register byte is updated with the new value or if the
  previous value is preserved.
- For vector store instructions, whether the store occurs or not.
- For vector load instructions, whether the value that is loaded or
  whether zeros are written to that element of the destination
  register.

This patch implements a pass that takes a hardware loop, containing
masked vector instructions, and converts it something that resembles
an MVE tail predicated loop. Currently, if we had code generation,
we'd generate a loop in which the VCTP would generate the predicate
and VPST would then setup the value of VPR.PO. The loads and stores
would be placed in VPT blocks so this is not tail predication, but
normal VPT predication with the predicate based upon a element
counting induction variable. Further work needs to be done to finally
produce a true tail predicated loop.

Because only the loads and stores are predicated, in both the LLVM IR
and MIR level, we will restrict support to only lane-wise operations
(no horizontal reductions). We will perform a final check on MIR
during loop finalisation too.

Another restriction, specific to MVE, is that all the vector
instructions need operate on the same number of elements. This is
because predication is performed at the byte level and this is set
on entry to the loop, or by the VCTP instead.

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

llvm-svn: 371179

[CodeGen] Do the Simple Early Return in block-placement pass to optimize the blocks

Summary:

Fix a bug of not update the jump table and recommit it again.

In `block-placement` pass, it will create some patterns for unconditional we can do the simple early retrun.
But the `early-ret` pass is before `block-placement`, we don't want to run it again.
This patch is to do the simple early return to optimize the blocks at the last of `block-placement`.

Reviewed By: efriedma

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

llvm-svn: 371177

[lldb][NFC] Remove unused Args::GetArgumentQuoteCharAtIndex

llvm-svn: 371176

[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC

llvm-svn: 371174

[CMake] LLVM_COMPILE_FLAGS also applies to C files

LLVM_COMPILE_FLAGS also applies to C files, otherwise tuning flags,
etc. won't be picked up.

https://reviews.llvm.org/D67171

llvm-svn: 371173

[lldb] Remove xcode bot from website listing and fix link to sanitized

llvm-svn: 371172

[MIR] Change test case to read from stdin instead of file

The

    ;CHECK: bb
    ;CHECK-NEXT: %namedVReg1353:_(p0) = COPY $d0

parts of the test case failed when the tests were placed in a directory
including "bb" in the path, since the full path of the file is then
output in the
 ; ModuleID = '/repo/bb/
line which the CHECK matched on and then the CHECK-NEXT failed.

llvm-svn: 371171

[X86] Add tests for extending and truncating between v16i8 and v16i64 with min-legal-vector-width=256.

It looks like we might be able to do these in fewer steps, but
I'm not sure.

llvm-svn: 371170

[X86] Prevent passing vectors of __int128 as <X x i128> in llvm IR

As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type.

I'm restricting this to change to Linux and NetBSD based on the
how similar ABI changes have been handled in the past.
PS4, FreeBSD, and Darwin are unaffected. I've also added a
new -fclang-abi-compat version to restore the old behavior.

This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment.

llvm-svn: 371169

[X86] Pre-commit vector of __int128 test cases for D64672.

llvm-svn: 371168

[X86] Fix bad indentation. NFC

llvm-svn: 371167

[Windows] Add support of watchpoints to `ProcessWindows`

Summary:
This patch adds support of watchpoints to the old `ProcessWindows` plugin.

The `ProcessWindows` plugin uses the `RegisterContext` to set and reset
watchpoints. The `RegisterContext` has some interface to access watchpoints,
but it is very limited (e.g. it is impossible to retrieve the last triggered
watchpoint with it), that's why I have implemented a slightly different
interface in the `RegisterContextWindows`. Moreover, I have made the
`ProcessWindows` plugin responsible for search of a vacant watchpoint slot,
because watchpoints exist per-process (not per-thread), then we can place
the same watchpoint in the same slot in different threads. With this scheme
threads don't need to have their own watchpoint lists, and it simplifies
identifying of the last triggered watchpoint.

Reviewers: asmith, stella.stamenova, amccarth

Reviewed By: amccarth

Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

llvm-svn: 371166

Fix rL371162 again

llvm-svn: 371164

Fix failing test from rL371162

llvm-svn: 371163

[yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headers

Summary: It says [[ http://www.sco.com/developers/gabi/latest/ch4.eheader.html | here ]] that if there are no program headers than e_phoff should be 0, but currently it is always set after the header. GNU's `readelf` (but not `llvm-readelf`) complains about this: `readelf: Warning: possibly corrupt ELF header - it has a non-zero program header offset, but no program headers`.

Reviewers: jhenderson, grimar, MaskRay, rupprecht

Reviewed By: jhenderson, grimar, MaskRay

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371162

gn build: Merge r371159

llvm-svn: 371161

Update SHT_LLVM_PART_EHDR test after r371157

llvm-svn: 371160

[MC] Fix undefined behavior in MCInstPrinter::formatHex

Passing INT64_MIN to MCInstPrinter::formatHex triggers undefined
behavior because the negation of -9223372036854775808 cannot be
represented in type 'int64_t' (aka 'long long'). This patch puts a
workaround in place to just print the hex value directly.

A possible alternative involves using a small helper functions that uses
(implementation) defined conversions to achieve the desirable value:

  static int64_t helper(int64_t V) {
    auto U = static_cast<uint64_t>(V);
    return V < 0 ? -U : U;
  }

The underlying problem is that MCInstPrinter::formatHex(int64_t) returns
a format_object<int64_t> and should really return a
format_object<uint64_t>. However, that's not possible because formatImm
needs to be able to print both as decimal (where a signed is required)
and hex (where we'd prefer to always have an unsigned).

  format_object<int64_t> formatImm(int64_t Value) const {
    return PrintImmHex ? formatHex(Value) : formatDec(Value);
  }

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

llvm-svn: 371159

Cleanup test.

llvm-svn: 371158

[llvm-readobj][yaml2obj] Support SHT_LLVM_SYMPART, SHT_LLVM_PART_EHDR and SHT_LLVM_PART_PHDR

See http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
and D60242 for the lld partition feature.

This patch:

* Teaches yaml2obj to parse the 3 section types.
* Teaches llvm-readobj/llvm-readelf to dump the 3 section types.

There is no test for SHT_LLVM_DEPENDENT_LIBRARIES in llvm-readobj. Add
it as well.

Reviewed By: thakis

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

llvm-svn: 371157