llvm-svn: 331131

These functions have been legacy leftovers which we used before the
official C++ bindings existed. As all uses of these legacy functions
have been removed, this polly-specific extension can also be dropped.

llvm-svn: 331130

llvm-svn: 331129

[X86] Use getX86SubSuperRegister in addGR32orGR64Operands in the AsmParser instead of duplicating its functionality. NFC

llvm-svn: 331128

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too.  Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

This moves over all uses of the macro, but doesn't remove the definition
of it in (llvm-)config.h yet.

llvm-svn: 331127

llvm-svn: 331126

llvm-svn: 331125

Found by opening config.h.cmake in vim, finding all defined macros with

  /define\(01\)\? \zs[A-Za-z0-9_]*<cr>
  :%s//\=setreg('A', submatch(0), 'V')/gn<cr>
  :put A<cr>

and then joining them all with |, and passing that to

  git grep -E that_pattern 'clang/*.h' 'clang/*.cpp' 'clang/*.c'

and diffing that output with the result of

  git grep Config/config.h 'clang/*.h' 'clang/*.cpp' 'clang/*.c'

No intended behavior change.

llvm-svn: 331124

Summary: Add bindings to create import declarations for modules, functions, types, and other entities.  This wraps the conveniences available in the existing DIBuilder API, but these seem C++-specific.

Reviewers: whitequark, harlanhaskins, deadalnix

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 331123

llvm-svn: 331122

llvm-svn: 331121

This moves more of Polly to islpp.

llvm-svn: 331120

We do this mostly by just moving directly to pure C++ code.

llvm-svn: 331119

llvm-svn: 331118

Many of these aliases exist to give one syntax or the other a slightly different mnemonic and the other variant gets a duplicate of its normal mnemonic

This patch restricts a lot of these to only one variant so we don't get the duplication.

This removes a lot of duplicate entries from the matcher table. It also reduces the number of warnings printed when you enable the ambiguous match warning in tablegen.

llvm-svn: 331117

Merge some remaining instregex entries.

llvm-svn: 331116

Summary:
Previously, a extending load was represented at (G_*EXT (G_LOAD x)).
This had a few drawbacks:
* G_LOAD had to be legal for all sizes you could extend from, even if
  registers didn't naturally hold those sizes.
* All sizes you could extend from had to be allocatable just in case the
  extend went missing (e.g. by optimization).
* At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we
  improve optimization of extends and truncates, this legality requirement
  would spread without considerable care w.r.t when certain combines were
  permitted.
* The SelectionDAG importer required some ugly and fragile pattern
  rewriting to translate patterns into this style.

This patch begins changing the representation to:
* (G_[SZ]EXTLOAD x)
* (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits()
which resolves these issues by allowing targets to work entirely in their
native register sizes, and by having a more direct translation from
SelectionDAG patterns.

This patch introduces the new generic instructions and new variation on
G_LOAD and adds lowering for them to convert back to the existing
representations.

Depends on D45466

Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, aemerson, javed.absar

Reviewed By: aemerson

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

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

llvm-svn: 331115

Summary:
* rL328953 does not include bindings for LLVMDIBuilderCreateClassType and LLVMDIBuilderCreateBitFieldMemberType despite declaring their prototypes.  Provide these bindings now.
* Switch to more precise types with specific numeric limits matching the DIBuilder's C++ API.

Reviewers: harlanhaskins, whitequark, deadalnix

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 331114

The delta to the previous version is rather small, but a change in brace
placement makes this a rather noisy commit.

llvm-svn: 331113

Summary:
Masked merge has a pattern of: `((x ^ y) & M) ^ y`.
But, there is no difference between `((x ^ y) & M) ^ y` and `((x ^ y) & ~M) ^ x`,
We should canonicalize the pattern to non-inverted mask.

https://rise4fun.com/Alive/Yol

Reviewers: spatel, craig.topper

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 331112

Summary:
Masked merge has a pattern of: `((x ^ y) & M) ^ y`.
But, there is no difference between `((x ^ y) & M) ^ y` and `((x ^ y) & ~M) ^ x`,
We should canonicalize the pattern to non-inverted mask.

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

llvm-svn: 331111

llvm-svn: 331110

llvm-svn: 331109

I intend to add further instruction tests to the resources-x86_64.s test file as required, but this initial commit is to help remove a load of unnecessary InstRW overrides in a future patch

llvm-svn: 331108

Make these arguments to the multiclass to allow easier specialization.

llvm-svn: 331107

Moved LAHF/SAHF to instrs instead of instregex.

Removed some unnecessary instregex entries.

llvm-svn: 331106

The instruction documentation specifically says that these instruction don't access memory.

llvm-svn: 331105

These instruction don't use their memory operands as normal memory operands. They're just used as addresses. They don't have a size because they aren't directly representing a load or store.

llvm-svn: 331104

This is a fix by elimination compiler warnings considered as errors.

llvm-svn: 331103

As far as I can tell from the docs, the instructions are automatically 64-bit in 64-bit mode. We don't need REX.W.

llvm-svn: 331102

Favor the 0x1a encoding for register/register move to match gas.

The instructions used RM and MR in their name along with rr/rm/mr at the end. To make more consistent with other instructions remove the RM/MR and use rr/rm/mr/rr_REV.

Hide the _REV encoding from the assembler but leave it for the disassembler.

llvm-svn: 331101

llvm-svn: 331100

The invocation of getExact in ScalarEvolution::getBackedgeTakenInfo is used
only for getting statistic and for assert. 
Even if statistics is disabled, the code related to it will be eliminated
the invocation to getExact itself will not be eliminated
because it may have side-effects like creation of new SCEVs.

So do invocation only when we collect statistics or executes asserts.

Reviewers: mkazantsev, sanjoy, javed.absar
Reviewed By: javed.absar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46178

llvm-svn: 331099

We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.

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

llvm-svn: 331098

llvm-svn: 331097

Patch by David Carlier!

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

llvm-svn: 331096

This commit makes it so that if you outline a def of some register, then the
call instruction created by the outliner actually reflects that the register
is defined by the call. It also makes it so that outlined functions don't
have the TracksLiveness property.

Outlined calls shouldn't break liveness assumptions that someone might make.

This also un-XFAILs the noredzone test, and updates the calls test.

llvm-svn: 331095

The effect of doing so is not disrupting the LoopPassManager when mixing this pass with other loop passes.  This should help locality of access substaintially and avoids the cost of computing PostDom.

The assumption here is that the full GuardWidening (which does use PostDom) is run as a canonicalization before loop opts and that this version is just catching cases exposed by other loop passes.  (i.e. LoopPredication, IndVarSimplify, LoopUnswitch, etc..)

llvm-svn: 331094

llvm-svn: 331093

Summary:
D42479 (rL329525) enabled SDIV combine for pow2 non-splat vector
dividers. But when there is a 1 in a vector, the instruction sequence to
be generated involves shifting a value by the number of its bit widths,
which is undefined
(https://github.com/llvm-mirror/llvm/blob/c64f4dbfe31e509f9c1092b951e524b056245af8/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L6000-L6006).

Especially, in architectures that do not support vector instructions,
each of element in a vector will be computed separately using scalar
operations, and then the resulting value will be undef for '1' values
in a vector.

(All 1's vector is fine; only vectors mixed with 1 and others will be
affected.)

Reviewers: RKSimon, jgravelle-google

Subscribers: jfb, dschuff, sbc100, jgravelle-google, llvm-commits

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

llvm-svn: 331092