llvm-svn: 345279

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

llvm-svn: 345278

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

llvm-svn: 345276

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

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

- 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

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

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

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

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

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

llvm-svn: 345267

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

Allows for better imported pattern re-use.

llvm-svn: 345265

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

Match codegen improvements from D53649/rL345256

llvm-svn: 345263

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

llvm-svn: 345262

llvm-svn: 345261

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

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

llvm-svn: 345257

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

Patch by squallatf@gmail.com

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

llvm-svn: 345255

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

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