llvm-svn: 296523

llvm-svn: 296521

This is somewhat tricky because there are two
pairs of tied operands, and it isn't allowed to be
VOP3 encoded.

llvm-svn: 296519

permits typedef union __attribute__((transparent_union)) {...}

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

llvm-svn: 296518

llvm-svn: 296517

MSDN documents that this function is not thread-safe, so we
wrap it in a global mutex.

llvm-svn: 296516

llvm-svn: 296515

Requesting DWARF v5 will now get you the new compile-unit and
type-unit headers.  llvm-dwarfdump will also recognize them.

Differential Revision: http://reviews.llvm.org/D30206

llvm-svn: 296514

llvm-svn: 296513

It's not clear to me if this is always better than
doing ds_write2_b64 This adds the constraint of
a 128-bit register input instead of a pair of
64-bit.

llvm-svn: 296512

llvm-svn: 296511

We converted them before, but there were a few remaining occurrences.

llvm-svn: 296510

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

llvm-svn: 296508

llvm-svn: 296507

If during scheduling we have identified that we cannot keep optimistic
occupancy increase critical register pressure limit and try scheduling
of the whole function again. In this case blocks with smaller pressure
will have a chance for better scheduling.

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

llvm-svn: 296506

I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.

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

llvm-svn: 296505

<rdar://problem/30735021>

llvm-svn: 296504

This reverts commit r296378.

I am pretty sure this is incorrect. In particular, for just

        .cfi_startproc
        nop
        .cfi_endproc

We now add an extra 4 zeros that neither bfd nor gold add.

llvm-svn: 296503

llvm-svn: 296502

llvm-svn: 296501

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

llvm-svn: 296500

Before:
  public enum VeryLongEnum {
    ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa",
                              "bbbbbbbbbbbbbbbbbbbbbbbbbbb",
                              "ccccccccccccccccccc")
    ,
    SECOND_ENUM("a", "b", "c");

    private VeryLongEnum(String a, String b, String c) {}
  }

After:
  public enum VeryLongEnum {
    ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa",
                              "bbbbbbbbbbbbbbbbbbbbbbbbbbb",
                              "ccccccccccccccccccc") ,
    SECOND_ENUM("a", "b", "c");

    private VeryLongEnum(String a, String b, String c) {}
  }

llvm-svn: 296499

Summary: For SamplePGO, the profile may contain cross-module inline stacks. As we need to make sure the profile annotation happens when all the hot inline stacks are expanded, we need to pass this info to the module importer so that it can import proper functions if necessary. This patch implemented this feature by emitting cross-module targets as part of function entry metadata. In the module-summary phase, the metadata is used to build call edges that points to functions need to be imported.

Reviewers: mehdi_amini, tejohnson

Reviewed By: tejohnson

Subscribers: davidxl, llvm-commits

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

llvm-svn: 296498

MSVC appears to be getting confused as to whether OverloadToken is
supposed to be public or not.

This was discovered by code in Swift, and has been reported to
microsoft by hughbe:
https://connect.microsoft.com/VisualStudio/feedback/details/3116517

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

llvm-svn: 296497

llvm-svn: 296496

This had broken as the result of some previous cleanup.

llvm-svn: 296495

This migrates the stream code away from MSFError to using its
own custom Error class.

llvm-svn: 296494

llvm-svn: 296493

llvm-svn: 296492

This change introduces new method to estimate register pressure in
GCNScheduler. Standard RPTracker gives huge error due to the following
reasons:

1. It does not account for live-ins or live-outs if value is not used
in the region itself. That creates a huge error in a very common case
if there are a lot of live-thu registers.
2. It does not properly count subregs.
3. It assumes a register used as an input operand can be reused as an
output. This is not always possible by itself, this is not what RA
will finally do in many cases for various reasons not limited to RA's
inability to do so, and this is not so if the value is actually a
live-thu.

In addition we can now see clear separation between live-in pressure
which we cannot change with the scheduling and tentative pressure
which we can change.

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

llvm-svn: 296491

Migrate all of aarch64-linux-gnu to \01_mcount instead of just when passing along gnueabi as this matches both gcc and what the kernel expects.

More of PR27311

llvm-svn: 296490

  - We do emit amd_kernel_code_t v1.1

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

llvm-svn: 296489

The LLVM backend cannot produce any debug info for an llvm::Function
without a DISubprogram attachment. When inlining a debug-info-carrying
function into a nodebug function, there is therefore no reason to keep
any debug info intrinsic calls or debug locations on the instructions.

This fixes a problem discovered in PR32042.

rdar://problem/30679307

llvm-svn: 296488

llvm-svn: 296487

[DAGISel] When checking if chain node is foldable, make sure the intermediate nodes have a single use across all results not just the result that was used to reach the chain node.

This recovers a test case that was severely broken by r296476, my making sure we don't create ADD/ADC that loads and stores when there is also a flag dependency.

llvm-svn: 296486

- remove path to dts-1.x (corresponds to gcc 4.7)
- add path to dts-6 (corresponds to 6.x)

Patch By: Maria Gottschalk

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

llvm-svn: 296485

If two subregs of the same register are defined and we need to revert
schedule changing def order, we will end up with both instructions
having def,read-undef flags because adjustLaneLiveness() will only set
this flag but will not remove it.

Fix this by removing read-undef flags before calling adjustLaneLiveness.

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

llvm-svn: 296484

Stack Smash Protection is not completely free, so in hot code, the overhead it causes can cause performance issues. By adding diagnostic information for which functions have SSP and why, a user can quickly determine what they can do to stop SSP being applied to a specific hot function.

This change adds a remark that is reported by the stack protection code when an instruction or attribute is encountered that causes SSP to be applied.

Patch by: James Henderson

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

llvm-svn: 296483

Patch By: Alexander Richardson

Reviewers: atanasyan, theraven, sdardis

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

llvm-svn: 296482

Summary:
The false positive happens on two neighbour CXXDefaultArgExpr AST nodes.
like below:

```
CXXFunctionalCastExpr 0x85c9670 <col:7, col:23> 'struct ZZ' functional cast to struct ZZ <ConstructorConversion>
 `-CXXConstructExpr 0x85c9518 <col:7, col:23> 'struct ZZ' 'void (uint64, const uint64 *)'
   |-CallExpr 0x85a0a90 <col:10, col:22> 'uint64':'unsigned long long'
   | |-ImplicitCastExpr 0x85a0a78 <col:10> 'uint64 (*)(uint64)' <FunctionToPointerDecay>
   | | `-DeclRefExpr 0x85a09f0 <col:10> 'uint64 (uint64)' lvalue Function 0x85a06a0 'Hash' 'uint64 (uint64)'
   | `-CXXDefaultArgExpr 0x85a0ac8 <<invalid sloc>> 'uint64':'unsigned long long'
   `-CXXDefaultArgExpr 0x85c94f8 <<invalid sloc>> 'const uint64 *'
```

For each particular CXXDefaultArgExpr node, we need to reset
FirstSubExpr, otherwise FirstSubExpr will refer to an incorrect expr.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: JDevlieghere, cfe-commits

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

llvm-svn: 296479