DebugInfo: Explain why DW_LLE_(GNU_)startx_length is used

This isn't the most object-size efficient encoding, but it's the only
one GDB supports for the pre-standard fission format. I've written fixes
for this twice now... - so perhaps this comment will help me remember
why neither of these have been committed and why I shouldn't try to
write a third fix another year from now...

llvm-svn: 345326

[x86] add tests for missed load folding; NFC

llvm-svn: 345325

[sanitizer] Fix mallopt interceptor.

On error, mallopt is supposed to return 0, not -1.

llvm-svn: 345323

[ELF] Don't check if symbols in .llvm.call-graph-profile are unorderable

Summary: There are too many reasonable cases that would be considered unorderable.

Reviewers: ruiu, espindola, Bigcheese

Reviewed By: ruiu

Subscribers: grimar, emaste, arichardson, llvm-commits

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

llvm-svn: 345322

[SystemZ]  Improve handling and cost estimates of vector integer div/rem

Enable the DAG optimization that converts vector div/rem with constants into
multiply+shifts sequences by expanding them early. This is needed since
ISD::SMUL_LOHI is 'Custom' lowered on SystemZ, and will therefore not be
available to BuildSDIV after legalization.

Better cost values for these instructions based on how they will be
implemented (a constant divisor is cheaper).

Review: Ulrich Weigand
https://reviews.llvm.org/D53196

llvm-svn: 345321

llvm-dwarfdump: loclists: Don't expect an (albeit empty) expression for LLE_base_address

llvm-svn: 345320

[Pipeliner] Ignore Artificial dependences while computing recurrences.

The artificial dependencies are not real dependencies. In some cases, they
form circuits with bigger MII. However, they are used to schedule instructions
better.

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

llvm-svn: 345319

[Pipeliner] Remove the unneeded include header(NFC).

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

llvm-svn: 345318

[X86] Change X86 backend to look for 'min-legal-vector-width' attribute instead of 'required-vector-width' when determining whether 512-bit vectors should be legal.

The required-vector-width attribute was only used for backend testing and has never been generated by clang.

I believe clang is now generating min-legal-vector-width for vector uses in user code.

With this I believe passing -mprefer-vector-width=256 to clang should prevent use of zmm registers in the generated assembly unless the user used a 512-bit intrinsic in their source code.

llvm-svn: 345317

[CodeGen] Remove operands from FENTRY_CALL

FENTRY_CALL is actually not taking any input / output operands. The
machine verifier complains now because the target description says that:

* It needs 1 unknown output
* It needs 1 or more variable inputs

llvm-svn: 345316

[AArch64] Create proper memoperand for multi-vector stores

Include all of the store's source vector operands when creating the
MachineMemOperand. Previously, we were missing the first operand,
making the store size seem smaller than it really is.

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

llvm-svn: 345315

Don't type-erase the FunctionNameType or TypeClass enums.

This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.

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

llvm-svn: 345314

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`.  We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with.  We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with.  This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically.  By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum.  This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313

[NFC] Refactor SetBaseClasses and DeleteBaseClasses.

We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses.  Every single caller
followed this exact 2-step process, and there was manual memory
management going on with raw pointers.  We can do better than this
by storing a vector of unique_ptrs and passing this around.
This makes for a cleaner API, and we only need to call one method
so there is no possibility of a user forgetting to call
DeleteBaseClassSpecifiers.

In addition to this, it also makes for a *simpler* API.  Part of
why I wanted to do this is because when I was implementing the native
PDB interface I had to spend some time understanding exactly what I
was deleting and why.  ClangAST has significant mental overhead
associated with it, and reducing the API surface can go along
way to making it simpler for people to understand.

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

llvm-svn: 345312

[C++17] Reject shadowing of capture by parameter in lambda

Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.

```
int main() {
  int a;
  auto f = [a](int a) { return a; };
}
```

results in:

```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
  auto f = [a](int a) { return a; };
                   ^
main.cpp:3:13: note: variable a is explicitly captured here
  auto f = [a](int a) { return a; };
            ^
```

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: lebedev.ri, erik.pilkington, cfe-commits

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

llvm-svn: 345308

[AArch64][GlobalISel] Simplify a legalizer test. NFC.

llvm-svn: 345307

Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"

This reverts commit b5d8d0de744d2c212bdb17d5c5fd4447dd14dbd2.

llvm-svn: 345306

[clang-tidy] Revert my readability-uppercase-literal-suffix check.

There are some lurking issues with the handling of the SourceManager.
Somehow sometimes we end up extracting completely wrong
portions of the source buffer.

Reverts r344772, r44760, r344758, r344755.

llvm-svn: 345305

Rebase defect report list.

llvm-svn: 345303

Change keep-static-consts to work on static storage duration, not
storage class.

To be more in line with what GCC does, switch the condition to be based
on the Static Storage duration instead of the storage class.

Change-Id: I8e959d762433cda48855099353bf3c950b9d54b8
llvm-svn: 345302

[WebAssembly] Bitselect and min/max builtins

Reviewers: aheejin, dschuff

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

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

llvm-svn: 345301

[WebAssembly] Lower to target-independent saturating add

Summary: Goes along with D53721.

Reviewers: aheejin, dschuff

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

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

llvm-svn: 345300

[WebAssembly] Use target-independent saturating add

Reviewers: aheejin, dschuff

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

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

llvm-svn: 345299

Implement Function Multiversioning for Non-ELF Systems.

Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.

This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.

The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions).  This is possible, since cpu-dispatch uses '.A'
for the 'default' version.

In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.

Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284

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

llvm-svn: 345298

[X86] Add some non-AVX512VL command lines to the *vl-vec-test-testn.ll tests.

This will expose some regressions in the WIP and/or/xor promotion removal patch.

llvm-svn: 345297

[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03

Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.

For example: https://godbolt.org/z/xXJELh

This patch fixes the confusion.

Reviewers: rsmith, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits

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

llvm-svn: 345296

[FPEnv] Last BinaryOperator::isFNeg(...) to m_FNeg(...) changes

Replacing BinaryOperator::isFNeg(...) to avoid regressions when we
separate FNeg from the FSub IR instruction.

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

llvm-svn: 345295

Remove full stops from error messages for consistency.

llvm-svn: 345294

[X86] Add KNL command lines to movmsk-cmp.ll.

Some of this code looks pretty bad and we should probably still be using movmskb more with avx512f.

llvm-svn: 345293

[GlobalISel] LegalizerHelper: Fix the incorrect alignment when splitting loads/stores in narrowScalar

Reviewers: dsanders, bogner, jpaquette, aemerson, ab, paquette

Reviewed By: dsanders

Subscribers: rovka, kristof.beyls, javed.absar, llvm-commits

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

llvm-svn: 345292

CodeGen: alter CFConstantString class name for swift 5.0

Swift 5.0 has changed the name decoration for swift symbols, using a 'S' sigil
rather than 's' as in 4.2.  Adopt the new convention.

llvm-svn: 345291

[LegalizeDAG] Remove dead SINT_TO_FP legalization code

As noticed on D52965, the SINT_TO_FP i64 to f32 legalization code has been dead for years - protected by an assert.

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

llvm-svn: 345290

fix incorrect placement of _LIBCPP_ALWAYS_INLINE in valarray

llvm-svn: 345289

[GISel] LegalizerInfo: Rename MemDesc::Size to SizeInBits to make the value clearer

Requested in D53679.

llvm-svn: 345288

Remove accidentally committed duplicate code

llvm-svn: 345287

[X86] Remove ProcIntelKNL and replace with a SlowPMADDWD flag to use in the one place it was checked.

llvm-svn: 345286

[X86] Remove some uarch tuning flags from KNL that look to have been inherited from SNB/IVB incorrectly

KNL is based on a modified Silvermont core so I don't think these features apply. I think the LEA flag is probably also wrong, but I'm less sure as I barely understand the 3 LEA flags we have currently.

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

llvm-svn: 345285

[analyzer] Move canReasonAbout from Z3ConstraintManager to SMTConstraintManager

Summary:
This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`.

The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent.

As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object?

Reviewers: george.karpenkov, NoQ

Reviewed By: george.karpenkov

Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp

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

llvm-svn: 345284

[analyzer] Fixed bitvector from model always being unsigned

Summary:
Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter.

This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`.

Reviewers: NoQ, george.karpenkov

Reviewed By: george.karpenkov

Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp

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

llvm-svn: 345283

[AArch64][GlobalISel] Fix the LegalityPredicate for lowerIf for G_LOAD/G_STORE

Summary:
Currently, Legalizer is trying to lower G_LOAD with a vector type
that has more than two elements due to the incorrect LegalityPredicate.

This patch fixes the issue by removing the multiplication by 8
as `MemDesc.Size` already contains the size in bits.

Reviewers: dsanders, aemerson

Reviewed By: dsanders

Subscribers: rovka, javed.absar, kristof.beyls, llvm-commits

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

llvm-svn: 345282

Implement sized deallocation for std::allocator and friends.

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: 345281

[llvm-mca] Introduce a new base class for mca::Instruction, and change how read/write information is stored.

This patch introduces a new base class for Instruction named InstructionBase.
Class InstructionBase is responsible for tracking data dependencies with the
help of ReadState and WriteState objects.  Class Instruction now derives from
InstructionBase, and adds extra information related to the `InstrStage` as well
as the `RCUTokenID`.

ReadState and WriteState objects are no longer unique pointers. This avoids
extra heap allocation and pointer checks that weren't really needed.  Now, those
objects are simply stored into SmallVectors.  We use a SmallVector instead of a
std::vector because we expect most instructions to only have a very small number
of reads and writes.  By using a simple SmallVector we also avoid extra heap
allocations most of the time.
In a debug build, this improves the performance of llvm-mca by roughly 10% (I
still have to verify the impact in performance on a release build).

llvm-svn: 345280

[AArch64] Refactor Exynos feature sets (NFC)

llvm-svn: 345279

Get rid of casts. (NFC)

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

llvm-svn: 345278

[OPENMP]Fix PR39422: variables are not firstprivatized in task context.

According to the OpenMP standard, In a task generating construct, if no
default clause is present, a variable for which the data-sharing
attribute is not determined by the rules above is firstprivatized.
Compiler tries to implement this, but if the variable is not directly
used in the task context, this variable may not be firstprivatized.
Patch fixes this problem.

llvm-svn: 345277

[ARM] Regenerate vdup tests

llvm-svn: 345276

[AArch64] Add EXT patterns for 64-bit EXT of a subvector of a 128-bit vector

If we have a 64-bit EXT where one of the operands is a subvector of a 128-bit
vector then in some cases we can eliminate an extract_subvector by converting
to a 128-bit EXT of the 128-bit vector.

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

llvm-svn: 345275

Fix a bug PlatformDarwin::SDKSupportsModule.

This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889.  VersionTuple::tryParse() can deal
with an optional third (micro) component, but the parse will fail when
there are extra characters after the version number (e.g.: trying to
parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails
after that patch).  Fixed here by stripping the ".sdk" suffix first.

(Part of) rdar://problem/45041492

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

llvm-svn: 345274

[AArch64] Branch Protection and Return Address Signing B Key Support

- Add support for -mbranch-protection=<type>[+<type>]* where
  - <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*]
- The protection emits relevant function attributes
  - sign-return-address=<scope>
  - sign-return-address-key=<key>
  - branch-protection

llvm-svn: 345273

[ARM] Use Cortex-A57 sched model for Cortex-A72

This mirrors what we already do for AArch64 as the cores are similar.
As discussed in the review, enabling the machine scheduler causes
more variations in performance changes so it is not enabled for now.
This patch improves LNT scores by a geomean of 1.57% at -O3.

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

llvm-svn: 345272

[AArch64] Refactor definition of EXT patterns to use a multiclass

Using a multiclass reduces duplication, and makes it easier to add new patterns
later. This refactoring does add some new patterns, but as far as I can tell
there's no IR that will end up triggering them so this is effectively NFC.

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

llvm-svn: 345271

[AArch64] Do 64-bit vector move of 0 and -1 by extracting from the 128-bit move

Currently a vector move of 0 or -1 will use different instructions depending on
the size of the vector. Using a single instruction (the 128-bit one) for both
gives more opportunity for Machine CSE to eliminate instructions.

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

llvm-svn: 345270

[DEBUG_INFO][NVPTX]Fix processing of DBG_VALUES.

Summary:
If the instruction in the eliminateFrameIndex function is a DBG_VALUE
instruction, it requires special processing. The frame register is set
to VRFrame and the offset is based on the object offset.
The code is similar to the code used in
lib/CodeGen/PrologEpilogInserter.cpp.

Reviewers: tra

Subscribers: jholewinski, llvm-commits

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

llvm-svn: 345269

[clangd] workspace/symbol should be async, it reads from the index.

Summary:
To enable this, TUScheduler has to provide a way to run async tasks without
needing a preamble or AST!

Reviewers: ilya-biryukov

Subscribers: javed.absar, ioeric, MaskRay, jkorous, arphaman, jfb, kadircet, cfe-commits

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

llvm-svn: 345268

update the clang doc about contributions

llvm-svn: 345267

[X86] Fix llc invocation on MIR test case

The current state of the llc invocation is:

* Running all the passes from dwarfehprepare to stack coloring
(included)
* It runs it from the LLVM IR included in the file
* It *ADDS* the generated MI from ISel to the MI in the MIR file
* The machine verifier doesn't like it.

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

llvm-svn: 345266

[GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index.

Allows for better imported pattern re-use.

llvm-svn: 345265

IR: Optimize StructType::get to perform one hash lookup instead of two, NFCI

Summary:
This function was performing two hash lookups when a new struct type was requested: first checking if it exists and second to insert it. This patch updates the function to perform a single hash lookup in this case by updating the value in the hash table in-place in case the struct type was not there before.

Similar to r345151.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: llvm-commits

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

llvm-svn: 345264

[CostModel][X86] Add realistic vXi64 uitofp vXf64 costs

Match codegen improvements from D53649/rL345256

llvm-svn: 345263

[RISCV] Use PatFrags for variable shift patterns

This follows SystemZ and I think is cleaner vs the multiclass.

llvm-svn: 345262

[CostModel][X86] Add realistic i64 uitofp f64 scalar costs

llvm-svn: 345261

[libc++] Make sure we can build libc++ with -fvisibility=hidden

Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.

The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.

Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.

Reviewers: EricWF

Subscribers: mgorny, christof, dexonsmith, libcxx-commits

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

llvm-svn: 345260

[llvm-mca] Removed a couple of redundant method declarations, and simplified code in ResourcePressureView. NFC

llvm-svn: 345259

[ms] Prevent explicit constructor name lookup if scope is missing

MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope.
This avoids a compile-time crash due to confusing a member access for a constructor name.

Test case included. All tests pass.

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

llvm-svn: 345258

Missing semicolon.

llvm-svn: 345257

[TargetLowering] Improve vXi64 UINT_TO_FP vXf64 support (P38226)

As suggested on D52965, this patch moves the i64 to f64 UINT_TO_FP expansion code from LegalizeDAG into TargetLowering and makes it available to LegalizeVectorOps as well.

Not only does this help perform X86 lowering as a true vectorization instead of (partially vectorized) scalar conversions, it avoids the HADDPD op from the scalar code which can be slow on most targets.

The AVX512F does have the vcvtusi2sdq scalar operation but we don't unroll to use it as it seems to only help for the v2f64 case - otherwise the unrolling cost will certainly be too high. My feeling is that we should leave it to the vectorizers - and if it generates the vector UINT_TO_FP we should use it.

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

llvm-svn: 345256

remove duplicate omp_control_tool export to fix windows build

Patch by squallatf@gmail.com

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

llvm-svn: 345255

[llvm-dwarfdump] - Fix incorrect parsing of the DW_LLE_startx_length

As was already mentioned in comments for D53364, DWARF 5
spec says about DW_LLE_startx_length:

"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. ")

Currently, the length is always parsed as U32.
Patch change the behavior to parse DW_LLE_startx_length as ULEB128 for DWARF 5
and keeps it as U32 for DWARF4+(pre-DWARF5) for compatibility.

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

llvm-svn: 345254

[TTI] Add generic SK_Broadcast shuffle costs

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

Fix MSVC llvm-exegesis build. NFCI.

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

[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG.

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

[LLDB] - Parse the DW_LLE_startx_length correctly for DWARF v5 case.

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

Add -instcombine-code-sinking option

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

[API] Extend the `SBThreadPlan` interface

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

[llvm-exegesis] Add missing initializer.

This is a better fix than rL345245.

llvm-svn: 345246

[llvm-exegesis] Fix VC build of r345243.

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

Make members non-const.

llvm-svn: 345245

[llvm-exegesis] Fix warning in r345243.

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

llvm-svn: 345244

[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

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

[clang-format] Break before next parameter after a formatted multiline raw string parameter

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

[X86] Don't use the OriginalDemandedBits to calculate the DemandedMask for PMULUDQ/PMULDQ inputs.

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

Revert "Fix use of __libcpp_deallocate in dynarray"

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

llvm-svn: 345240

Temporarily Revert "Implement sized deallocation for std::allocator and friends."

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

[llvm-readobj] Print ELF header flags names in GNU output

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

[CodeGen] Always emit the 'min-legal-vector-width' attribute even when the value is 0.

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

[X86] Fix typo in comment. NFC

llvm-svn: 345236

[clangd] Clean up LSP structs around configuration. NFC, no protocol changes.

 - 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

Fix use of __libcpp_deallocate in dynarray

llvm-svn: 345234

[clangd] Remove unused CDB function. NFC

llvm-svn: 345233

[clangd] Fix -compile-commands-dir flag, broken in r345031

llvm-svn: 345232

[clangd] Don't invalidate LSP-set compile commands when closing a file.

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

[WebAssembly] Set LoadExt and TruncStore actions for SIMD types

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

Fix test to work on Windows.

llvm-svn: 345229

[Sema] Fix -Wcomma for C89

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

[X86] Adjust MIR test case to pacify machine verifier

llvm-svn: 345227

[X86] Fix pipeline tests when enabling MIR verification, NFC

llvm-svn: 345226

Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"

This reverts commit 6f47cdd51341344c0e32630e19e72c94cd25f34e.

llvm-svn: 345225

DebugInfo: Reuse common addresses for rnglist base address selections

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

[WebAssembly] Fix immediate of rethrow when throwing to caller

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

Driver,CodeGen: introduce support for Swift CFString layout

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