Check if a single cast is preventing handling a first-order-recurrence Phi,
because the scheduling constraints it imposes on the first-order-recurrence
shuffle are infeasible; but they can be made feasible by moving the cast
downwards. Record such casts and move them when vectorizing the loop.

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

llvm-svn: 306884

The root cause of the issues reported in D32406 and D34680 is that clang
instruments functions without bodies. Make it stop doing that, and also
teach it how to use old (incorrectly generated) profiles without
crashing.

llvm-svn: 306883

llvm-svn: 306882

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306881

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306880

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306879

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding updates to clang, clang-tools-extra, and lld to follow.

llvm-svn: 306878

The llvm flag "-hexagon-emit-lookup-tables" guards the generation
of lookup table generated from a switch statement.
Differential Revision: https://reviews.llvm.org/D34819

llvm-svn: 306877

This adds all remaining instructions that were still missing, mostly
privileged and semi-privileged system-level instructions.  These are
provided for use with the assembler and disassembler only.

This brings the LLVM assembler / disassembler to parity with the
GNU binutils tools.

llvm-svn: 306876

It looks like there are two target-independent but not GISel instructions that
need legalization, IMPLICIT_DEF and PHI. These are already anomalies since
their operands have important LLTs attached, so to make things more uniform it
seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF.

llvm-svn: 306875

Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace

The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).

These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:

  class Foo
  {};

In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:

  class Foo
  { void Foo(); };

This is now properly formatted as:

  class Foo
  {
     void Foo();
  };

Reviewers: djasper, krasimir

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

llvm-svn: 306874

llvm-svn: 306873

This patch adds a new LLVM flag -hexagon-emit-jt-text which is defaulted to 
"false". The value "true" emits the switch generated jump tables in text section.
Differential Revision: https://reviews.llvm.org/D34820

llvm-svn: 306872

    
This reverts commit ae521f4192c3ed0202c047fec993cb59133dd1a0.
Wrong commit message

llvm-svn: 306871

The llvm flag "-hexagon-emit-lookup-tables" guards the generation
of lookup table from a switch statement.

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

llvm-svn: 306869

Summary:
This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:

  static int types[] = {
      registerType1(),
      registerType2(),
      registerType3(),
  };
  std::map<int, std::string> x = {
      { 0, "foo fjakfjaklf kljj" },
      { 1, "bar fjakfjaklf kljj" },
      { 2, "stuff fjakfjaklf kljj" },
  };

This is similar to how dictionnaries are formatted, and actually corresponds to the same conditions: when initializing a container (and not just 'calling' a constructor).

Such formatting involves 2 things:
* Line breaks around the content of the block. This can be forced by adding a comma or comment after the last element
* Elements should not be binpacked

This patch considers the block is an initializer list if it either ends with a comma, or follows an assignment, which seems to provide a sensible approximation.

Reviewers: krasimir, djasper

Reviewed By: djasper

Subscribers: malcolm.parsons, klimek, cfe-commits

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

llvm-svn: 306868

This patch appends the name of the function to the switch generated lookup
table. This will ease the visual debugging in identifying the function the table
is generated from.

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

llvm-svn: 306867

Summary:
Depends on https://reviews.llvm.org/D34865.

With the Clang uses of the old spelling having been removed in
https://reviews.llvm.org/D34865, get rid of the old "diagnostic hotness"
spellings in favor of the new "diagnostics hotness".

Reviewers: anemet, davidxl

Reviewed By: anemet

Subscribers: llvm-commits

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

llvm-svn: 306866

On big-endian machines the high and low parts of the value accessed by ldrexd
and strexd are swapped around. To account for this we swap inputs and outputs
in ISelLowering.

Patch by Bharathi Seshadri.

llvm-svn: 306865

Make 0 argument getSubtargetImpl functions for the X86, AArch64, and PPC targets deleted so that no one is tempted to use them.

llvm-svn: 306864

Summary:
Introduce a "hybrid" `-polly-target` option to optimise code for either the GPU or CPU.

When this target is selected, PPCGCodeGeneration will attempt first to optimise a Scop. If the Scop isn't modified, it is then sent to the passes that form the CPU pipeline, i.e. IslScheduleOptimizerPass, IslAstInfoWrapperPass and CodeGeneration.

In case the Scop is modified, it is marked to be skipped by the subsequent CPU optimisation passes.

Reviewers: grosser, Meinersbur, bollu

Reviewed By: grosser

Subscribers: kbarton, nemanjai, pollydev

Tags: #polly

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

llvm-svn: 306863

Summary:
Depends on https://reviews.llvm.org/D34864.

To unify Clang and LLVM's spelling of "diagnostic[s] hotness", use the
new "diagnostics hotness" spelling in LLVM, which was added in
https://reviews.llvm.org/D34864.

Reviewers: anemet, davidxl

Reviewed By: anemet

Subscribers: cfe-commits

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

llvm-svn: 306862

The existing check lines were more flexible, but these are
small enough tests that there shouldn't be much question
about register allocation. I've been hand-modifying this 
file as I change the CGP memcmp expansion, but that's
more error-prone and time-consuming than just running the 
update script.

llvm-svn: 306861

llvm-svn: 306860

This reverts commit r306310.

r306310 causes clang to reject a call to an aligned allocation or
deallocation function if it is not implemented in the standard library
of the deployment target. This is not the desired behavior when users
have defined their own aligned functions.

rdar://problem/32664169

llvm-svn: 306859

Working with git on a branch I find it really annoying that committing
a change causes ninja to think that stuff needs to be rebuilt.

With this change at least nothing in llvm needs to be rebuild when
something is committed.

llvm-svn: 306858

Introduced in -r283004, the PassNameParser sorts Optimization options in 
reverse. This is because the commit replaced a compare function with "<" 
(which would seemingly be proper based on the name of the comparison function). 
The result is the 'true' result is converted to '1', which is inverted.

This patch fixes this by replacing the '<' operator call on StringRef with a 
call to the StringRef compare function. It also renames the function to better 
reflect its meaning.

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

llvm-svn: 306857

llvm-svn: 306856

I'm tired of seeing this:
        .globl  "?Test@@YAXXZ"          # -- Begin function ^A?Test@@YAXXZ

llvm-svn: 306855

Summary:
There have been bugs with the WindowsResource library, such as incorrect
symbols for addresses.  Directly checking the .rsrc in the final PE will
help ensure this doesn't happen again.

Subscribers: llvm-commits

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

llvm-svn: 306854

Symbols in the resource COFF file should be for .rsrc$02, where the
actual resource data is, not .rsrc$01, which contains the directory
tree.

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

Patch by Joe Ranieri.

llvm-svn: 306853

Previously we had the -type-index option which would dump the record of
a single, but we had no way to follow the dependency graph backwards and
also dump all dependent types.

Having this option makes test-writing better, because we can limit the
test to only those records that are of importance for the thing we're
trying to test, which allows us to use things like CHECK-NEXT to reduce
fragility.

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

llvm-svn: 306852

Diffential Revision: https://reviews.llvm.org/D34842

llvm-svn: 306851

llvm-svn: 306850

[X86] Move all atom CPUs to the same section of the switch and use fallthroughs like we do for other CPU generations. NFC

This is prep work to add MOVBE to all Atom CPUs. This instruction didn't come in to the Nehalem/Westmere/SandyBridge/etc. line until later so there's no natural place to overlap the Atom CPUs into that part of the switch.

llvm-svn: 306849

Summary:
To enable profile hotness information in diagnostics output, Clang takes
the option `-fdiagnostics-show-hotness` -- that's "diagnostics", with an
"s" at the end. Clang also defines `CodeGenOptions::DiagnosticsWithHotness`.

LLVM, on the other hand, defines
`LLVMContext::getDiagnosticHotnessRequested` -- that's "diagnostic", not
"diagnostics". It's a small difference, but it's confusing, typo-inducing, and
frustrating.

Add a new method with the spelling "diagnostics", and "deprecate" the
old spelling.

Reviewers: anemet, davidxl

Reviewed By: anemet

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 306848

llvm-svn: 306847

Summary:
Runtime unrolling is done for loops with a single exit block and a
single exiting block (and this exiting block should be the latch block).
This patch adds logic to support unrolling in the presence of multiple exit
blocks (which also means multiple exiting blocks).
Currently this is under an off-by-default option and is supported when
epilog code is generated. Support in presence of prolog code will be in
a future patch (we just need to add more tests, and update comments).

This patch is essentially an implementation patch. I have not added any
heuristic (in terms of branches added or code size) to decide when
this should be enabled.

Reviewers: mkuper, sanjoy, reames, evstupac

Reviewed by: reames

Subscribers: llvm-commits

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

llvm-svn: 306846

Summary:
An attempt to reland D34786 (which caused bot failres on Mac), now with
properly intercepted operators new() and delete().

LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 306845

llvm-svn: 306844