I noticed while fixing PR39368 that we don't have generic shuffle costs for broadcast style shuffles.

This patch adds SK_BROADCAST handling, but exposes ARM/AARCH64 lack of handling of this type, which I've added a fix for at the same time.

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

llvm-svn: 345253

MSVC is a bit funny about is_pod.....

llvm-svn: 345252

Recommit r345127 "[LLDB] - Add support for DW_RLE_base_address and DW_RLE_offset_pair entries (.debug_rnglists)"

With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was
omited/forgotten/removed by mistake.

Original commit message:

The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries

Differential revision: https://reviews.llvm.org/D53140
----
Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml
Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

llvm-svn: 345251

When SimplifyCFG changes the PHI node into a select instruction, the debug line records becomes ambiguous. It causes the debugger to display unreachable source lines.

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

llvm-svn: 345250

Currently, we always parse the length field of DW_LLE_startx_length entry as U32.
That is correct for pre-standard definition:

https://gcc.gnu.org/wiki/DebugFission - "A start/length entry contains one unsigned LEB128 number
and a 4-byte unsigned value (as would be represented by the form code DW_FORM_const4u). The first
number is an index into the .debug_addr section that selects the beginning offset, and the second
number is the length of the range. ")

But DWARF v5 says: "This is a form of bounded location description that has two unsigned ULEB operands.
The first value is an address index (into the .debug_addr section) that indicates the beginning of the address
range over which the location is valid. The second value is the length of the range."

Fortunately, we can easily handle the difference. No test case because it seems impossible to test
until we will be ready to use DWARF v5 in tests that need to run the executables.

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

llvm-svn: 345249

Reviewers: craig.topper, andrew.w.kaylor, efriedma

Reviewed By: craig.topper, andrew.w.kaylor, efriedma

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

llvm-svn: 345248

Summary:
This patch extends the `SBThreadPlan` to allow retrieving of thread plans
for scripted steps.

Reviewers: labath, zturner, jingham

Reviewed By: jingham

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 345247

This is a better fix than rL345245.

llvm-svn: 345246

"const members cannot be default initialized unless their type has a user defined default constructor"

Make members non-const.

llvm-svn: 345245

warning C4099: 'llvm::exegesis::PfmCountersInfo': type name first seen using 'class' now seen using 'struct'

llvm-svn: 345244

Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).

This also compresses the pfm counter tables (PR37068).

Reviewers: RKSimon, gchatelet

Subscribers: mgrang, llvm-commits

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

llvm-svn: 345243

Summary:
Currently clang-format breaks before the next parameter after multiline parameters (also recursively for the parent expressions of multiline parameters). However, it fails to do so for formatted multiline raw string literals:
```
$ cat test.cc
// Examples

// Regular multiline tokens
int x = f(R"(multi
             line)", 2);
}

int y = g(h(R"(multi
              line)"), 2);

// Formatted multiline tokens
int z = f(R"pb(multi: 1  #
               line: 2)pb", 2);

int w = g(h(R"pb(multi: 1  #
                 line: 2)pb"), 2);
$ clang-format -style=google test.cc
// Examples

// Regular multiline tokens
int x = f(R"(multi
             line)",
          2);
}

int y = g(h(R"(multi
              line)"),
          2);

// Formatted multiline tokens
int z = f(R"pb(multi: 1  #
               line: 2)pb", 2);

int w = g(h(R"pb(multi: 1  #
                 line: 2)pb"), 2);
```

This patch addresses this inconsistency by forcing breaking after multiline formatted raw string literals. This requires a little tweak to the indentation chosen for the contents of a formatted raw string literal: in case when that's a parameter and not the last one, the indentation is based off of the uniform indentation of all of the parameters.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

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

llvm-svn: 345242

Multiply a is complex operation so just because some bit of the output isn't used doesn't mean that bit of the input isn't used.

We might able to bound it, but it will require some more thought.

llvm-svn: 345241

This reverts commit r345234 as it depended on the sized deallocation commit.

llvm-svn: 345240

This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/1428

This reverts commit r345214.

llvm-svn: 345239

GNU readelf tool prints hex value of the ELF header flags field and the
flags names. This change adds the same functionality to llvm-readobj.
Now llvm-readobj can print MIPS and RISCV flags.

New GNUStyle::printFlags() method is a copy of ScopedPrinter::printFlags()
routine. Probably we can escape code duplication and / or simplify the
printFlags() method. But it's a task for separate commit.

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

llvm-svn: 345238

The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to assume large vectors may be present.

llvm-svn: 345237

llvm-svn: 345236

 - align struct names/comments with LSP, remove redundant "clangd" prefixes.
 - don't map config structs as Optional<> when their presence/absence
   doesn't signal anything and all fields must have sensible "absent" values
 - be more lax around parsing of 'any'-typed messages

llvm-svn: 345235

llvm-svn: 345234

llvm-svn: 345233

llvm-svn: 345232

Summary:
It doesn't make much sense: setting them is not coupled to opening the file,
it's an asynchronous notification.

I don't think this is a breaking change - this behavior is hard to observe!

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

llvm-svn: 345231

Summary: Fixes part of the problem reported in bug 39275.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits, alexcrichton

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

llvm-svn: 345230

llvm-svn: 345229

There is a small difference in the scope flags for C89 versus the other C/C++
dialects.  This change ensures that the -Wcomma warning won't be duplicated or
issued in the wrong location.  Also, the test case is refactored into C and C++
parts, with the C++ parts guarded by a #ifdef to allow the test to run in both
modes.

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

llvm-svn: 345228

llvm-svn: 345227

llvm-svn: 345226

This reverts commit 6f47cdd51341344c0e32630e19e72c94cd25f34e.

llvm-svn: 345225

This makes the offsets larger (since they are further from the base
address) but those are in the .dwo - and allows removing addresses and
relocations from the .o file.

This could be built into the AddressPool more fundamentally, perhaps -
when you ask for an AddressPool entry you could say "or give me some
other entry and an offset I need to use" - though what to do about
situations where the first use of an address in a section is not the
earliest address in that section... is tricky.

At least with range addresses we can be fairly sure we've seen the
earliest address first because we see the start address for the
function.

llvm-svn: 345224

Summary:
Currently when assigning depths 'rethrow' does not take the whole
control flow stack into accounts but only considers EH pad stacks. When
assigning depth immmediates to rethrows, in normal cases it is done
correctly but when a rethrow instruction throws up to a caller, i.e., we
convert a pseudo RETHROW_TO_CALLER instruction to a rethrow, it
mistakenly compute the whole stack depth.

Reviewers: dschuff

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

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

llvm-svn: 345223

Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation.  This controls the language interoperability.
In particular, this is relevant for generating the CFConstantString classes
(primarily through the `__builtin___CFStringMakeConstantString` builtin) which
construct a reference to the "CFObject"'s `isa` field.  This type differs
between swift 4.1 and 4.2+.

Valid values for the new option include:
  - objc [default behaviour] - enable ObjectiveC interoperability
  - swift-4.1 - enable interoperability with swift 4.1
  - swift-4.2 - enable interoperability with swift 4.2
  - swift-5.0 - enable interoperability with swift 5.0
  - swift [alias] - target the latest swift ABI

Furthermore, swift 4.2+ changed the layout for the CFString when building
CoreFoundation *without* ObjectiveC interoperability.  In such a case, a field
was added to the CFObject base type changing it from: <{ const int*, int }> to
<{ uintptr_t, uintptr_t, uint64_t }>.

In swift 5.0, the CFString type will be further adjusted to change the length
from a uint32_t on everything but BE LP64 targets to uint64_t.

Note that the default behaviour for clang remains unchanged and the new layout
must be explicitly opted into via `-fcf-runtime-abi=swift*`.

llvm-svn: 345222

Summary:
Changing the node type in lowering was violating assumptions made in
the DAG combiner, so don't change the node type any more. This fixes
one of the issues reported in bug 39275.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits, alexcrichton

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

llvm-svn: 345221

Reviewers: aheejin, dschuff

Subscribers: llvm-commits

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

llvm-svn: 345220

Instead of using the MOVGOT64r pseudo, use the existing
MO_PIC_BASE_OFFSET support on symbol operands. Now I don't have to
create a "scratch register operand" for the pseudo to use, and the
register allocator can make better decisions.

Fixes some X86 verifier errors tracked in PR27481.

llvm-svn: 345219

Summary:
Changes all uses of minnan/maxnan to minimum/maximum
globally. These names emphasize that the semantic difference between
these operations is more than just NaN-propagation.

Reviewers: arsenm, aheejin, dschuff, javed.absar

Subscribers: jholewinski, sdardis, wdng, sbc100, jgravelle-google, jrtc27, atanasyan, llvm-commits

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

llvm-svn: 345218

In this diff we introduce dispatch mechanism based on 
the type of the input (archive, object file, raw binary) 
and the format (coff, elf, macho).
We also move the ELF-specific code into the namespace llvm::objcopy::elf.

Test plan: make check-all

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

llvm-svn: 345217

Summary:
Teach LoopRotate to preserve MemorySSA.
Enable tests for correctness, dependency disabled by default.

Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits

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

llvm-svn: 345216

llvm-dwarfdump: Account for skeleton addr_base when dumping addresses in split unit in the same file

llvm-svn: 345215

Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).

This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.

On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.

Reviewers: ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: rsmith, ckennelly, libcxx-commits, christof

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

llvm-svn: 345214