Compiler.h is used by Demangle (which Support depends on) - so sink it
into Demangle to avoid a circular dependency

DataTypes.h is used by llvm-c (which Support depends on) - so sink it
into llvm-c.

DataTypes.h could probably be fixed the other way - making llvm-c depend
on Support instead of Support depending on llvm-c - if anyone feels
that's the better option, happy to work with them on that.

I /think/ this'll address the layering issues that previous attempts to
commit this have triggered in the Modules buildbot, but I haven't been
able to reproduce that build so can't say for sure. If anyone's having
trouble with this - it might be worth taking a look to see if there's a
quick fix/something small I missed rather than revert, but no worries.

llvm-svn: 328123

llvm-svn: 328122

llvm-svn: 328121

Add barrier edges to check for any physical register. The previous code
worked for the function return registers: r0/d0, v0/w0.

Patch by Brendon Cahoon.

llvm-svn: 328120

This is part of solving:
https://bugs.llvm.org/show_bug.cgi?id=36682

There's also a leftover improvement from the long-ago-closed:
https://bugs.llvm.org/show_bug.cgi?id=5438

https://rise4fun.com/Alive/dC1

llvm-svn: 328119

Summary:
Recursive lookups are handled by the Resolver, so the loop was purely
a waste of runtime.

Change-Id: I2bd23a68b478aea0bbac1a86ca7635adffa28688

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 328118

Summary:
Instantiating def's and defm's needs to perform the following steps:

- for defm's, clone multiclass def prototypes and subsitute template args
- for def's and defm's, add subclass definitions, substituting template
  args
- clone the record based on foreach loops and substitute loop iteration
  variables
- override record variables based on the global 'let' stack
- resolve the record name (this should be simple, but unfortunately it's
  not due to existing .td files relying on rather silly implementation
  details)
- for def(m)s in multiclasses, add the unresolved record as a multiclass
  prototype
- for top-level def(m)s, resolve all internal variable references and add
  them to the record keeper and any active defsets

This change streamlines how we go through these steps, by having both
def's and defm's feed into a single addDef() method that handles foreach,
final resolve, and routing the record to the right place.

This happens to make foreach inside of multiclasses work, as the new
test case demonstrates. Previously, foreach inside multiclasses was not
forbidden by the parser, but it was de facto broken.

Another side effect is that the order of "instantiated from" notes in error
messages is reversed, as the modified test case shows. This is arguably
clearer, since the initial error message ends up pointing directly to
whatever triggered the error, and subsequent notes will point to increasingly
outer layers of multiclasses. This is consistent with how C++ compilers
report nested #includes and nested template instantiations.

Change-Id: Ica146d0db2bc133dd7ed88054371becf24320447

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 328117

llvm-svn: 328116

The pipeliner needs to remove instructions from the SlotIndexes
structure when they are deleted. Otherwise, the SlotIndexes map
has stale data, and an assert will occur when adding new
instructions.

This patch also changes the pipeliner to make the back-edge of
a loop carried dependence 1 cycle. The 1 cycle latency is added
to the anti-dependence that represents the back-edge. This
changes eliminates a couple of hacks added to the pipeliner to
handle the latency of the back-edge. It is needed to correctly
pipeline the test case for the sub-register elimination pass.

llvm-svn: 328113

llvm-svn: 328112

[X86][Haswell] Merge multiple InstrRW entries that map to the same SchedWriteRes group (NFCI) (PR35955)

I've also merged some VEX/non-VEX instregex strings with a (V?) prefix or (Y?) ymm variant - there are still a lot more of these to do.

llvm-svn: 328111

llvm-svn: 328110

llvm-svn: 328109

llvm-svn: 328105

This patch also includes extensive tests targeted at select and br+fcmp IR
inputs. A sequence of br+fcmp required support for FPR32 registers to be added
to RISCVInstrInfo::storeRegToStackSlot and
RISCVInstrInfo::loadRegFromStackSlot.

llvm-svn: 328104

llvm-svn: 328102

Summary:
I recently added a new dynamic tag to our fork of LLVM and when adding it
to llvm-readobj I noticed that not all DT_ values were being handled there.

Using macros in a .def file that can be included by both ELFDumper.cpp and
the ELF.h header ensures that the two don't get out of sync when new values
are added.

Reviewers: grimar, pcc, davide, espindola

Reviewed By: grimar, espindola

Subscribers: srhines, llvm-commits

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

llvm-svn: 328099

We were inconsistent, sometimes even within a single sentence.
The consensus seems clear that the FP we're looking for is
spelled "floating-point". Without the hyphen, it's a 
"surprisingly fine" jazz album.

llvm-svn: 328098

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
MemCpyOpt pass to cease using:
1) The old getAlignment() API of MemoryIntrinsic in favour of getting source & dest specific
alignments through the new API.
2) The old IRBuilder CreateMemCpy/CreateMemMove single-alignment APIs in favour of the new
API that allows setting source and destination alignments independently.

We also add a few tests to fill gaps in the testing of this pass.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774,
rL324781, rL324784, rL324955, rL324960, rL325816, rL327398, rL327421 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 328097

Summary:
If the operands of a udiv/urem can be proved to fit within a smaller
power-of-two-sized type, reduce the width of the udiv/urem.

Backed out for causing performance regressions.  Re-landing
because we've determined that these regressions were noise.

Original Differential Revision: https://reviews.llvm.org/D44102

llvm-svn: 328096

This reverts r328065.

I missed this one in r328085 and the bots were still failing.

llvm-svn: 328095

Removed a couple of methods from DispatchUnit.

llvm-svn: 328094

- constexpr is needed for out-of-class definition of the Type static
  member by some compilers
- MSVC is confused by the initialization of the static constexpr char[]
  member when it happens in a template specialization. Explicitly
  specifying the length of the array seems to be enough to help it
  figure things out.

llvm-svn: 328093

Summary:
We have had at least three pieces of code (in DWARFAbbreviationDeclaration,
DWARFAcceleratorTable and DWARFDie) that have hand-rolled support for
dumping unknown dwarf enum values. While not terrible, they are a bit
distracting and enable small differences to creep in (Unknown_ffff vs.
Unknown_0xffff). I ended up needing to add a fourth place
(DWARFVerifier), so it seems it would be a good time to centralize.

This patch creates an alternative to the XXXString dumping functions in
the BinaryFormat library, which formats an unknown value as
DW_TYPE_unknown_1234, instead of just an empty string. It is based on
the formatv function, as that allows us to avoid materializing the
string for unknown values (and because this way I don't have to invent a
name for the new functions :P).

In this patch I add formatters for dwarf attributes, forms, tags, and
index attributes as these are the ones in use currently, but adding
other enums is straight-forward.

Reviewers: dblaikie, JDevlieghere, aprantl

Subscribers: llvm-commits

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

llvm-svn: 328090

This reverts:
  r328072 "Move Compiler.h from Support to Demangler to fix layering."
  r328073 "Fix the actual user of DataTypes.h in llvm-c to avoid the circular dependency"

Failing bots:
  http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/
  http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/

llvm-svn: 328085

Summary:
When building the selection DAG we sometimes need to postpone
the handling of a dbg.value until the value it should refer to
is created. This is done by using the DanglingDebugInfoMap.
In the past this map has been limited to hold one dangling
dbg.value per value. This patch removes that restriction.

Reviewers: aprantl, rnk, probinson, vsk

Reviewed By: aprantl

Subscribers: Ka-Ka, llvm-commits, JDevlieghere

Tags: #debug-info

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

llvm-svn: 328084

Fix build bot after r328078 "llvm-readobj] - Teach llvm-readobj to dump .note.gnu.property sections."

BB was: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/27058/steps/test/logs/stdio

llvm-svn: 328080

NT_GNU_PROPERTY_TYPE_0 is a recently added type of .note.gnu.property
section specified in Linux Extensions to gABI.
(https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI)

Patch teach tool to print such notes properly.

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

llvm-svn: 328078

[X86][Broadwell] Merge multiple InstrRW entries that map to the same SchedWriteRes group (NFCI) (PR35955)

llvm-svn: 328076

llvm-svn: 328075

It's only called from one place and is defined just above that use.

llvm-svn: 328074

(follow-up to r328065)

llvm-svn: 328073

Support depends on Demangle (Support/Unix/Signals.inc), so Demangle
including Support/Compiler.h created a circular dependency.

Leave a forwarding shim of Compiler.h because it makes more sense for
users (a deeper fix might involve splitting Support into lower and upper
Support - but that also sounds a bit weird/awkward) than thinking about
the dependency on the Demangler.

llvm-svn: 328072

llvm-svn: 328071

Summary:
This code previously had a SmallVector of std::pairs containing an unsigned and another SmallVector. The outer vector was using the unsigned effectively as a key to decide which SmallVector to add into. So each time something new needed to be added the out vector needed to be scanned. If it wasn't found a new entry needed to be added to be added. This sounds very much like a map, but the next loop iterates over the outer vector to get a deterministic order.

We can simplify this code greatly if use SmallMapVector instead. This uses more stack space since we now have a vector and a map, but the searching and creating new entries all happens behind the scenes. It should also make the search more efficient though usually there are only a few entries so that doesn't matter much.

We could probably get determinism by just using std::map which would iterate over the unsigned key, but that would generate different output from what we get with the current implementation.

Reviewers: RKSimon, dblaikie

Reviewed By: dblaikie

Subscribers: llvm-commits

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

llvm-svn: 328070

Support depends on llvm-c (a few typedefs, macros, etc - Types.h,
Disassembler.h, and TargetMachine.h.

This could be done the other way - those macros/typedefs/etc could be
moved into Support and used from llvm-c instead. If someone feels that's
a better direction to go, happy to discuss it/try it out/etc.

llvm-svn: 328065

Also restrict to port 0 and 1 for SkylakeClient. It looks like the scheduler models don't account for client not having a full vector ALU on port 5 like server.

Fixes PR36808.

llvm-svn: 328061

Most basic possible test for the logic used by LICM.

Also contains a speculative build fix for compiles which complain about a definition of a stuct K; followed by a declaration as class K;

llvm-svn: 328058

The tests compile after r328049

llvm-svn: 328057

(Currently showing without, will enable and check in diff to show impact)

llvm-svn: 328056