Reordered the data tables at the top and placed the lookups after. The first stage in the yak shaving necessary to get more accurate costs for a variety of targets given the recent improvements to SINT_TO_FP/UINT_TO_FP/SIGN_EXTEND vector lowering.

llvm-svn: 242643

Not sure if the optimizer will save the call as getCalledFunction()
is not a trivial access function but the code is clearer this way.

llvm-svn: 242641

We don't bitcast the UNDEFs - that is done in visitVECTOR_SHUFFLE, and the getValueType should come from the operand's SDValue not the SDNode.

llvm-svn: 242640

Differential Revision: http://reviews.llvm.org/D11257
Patch by: marina.yatsina@intel.com

llvm-svn: 242639

canFoldMemoryOperand is not actually used anywhere in the codebase - all existing users instead call foldMemoryOperand directly when they wish to fold and can correctly deduce what they need from the return value. 

This patch removes the canFoldMemoryOperand base function and the target implementations; only x86 had a real (bit-rotted) implementation, although AMDGPU had a preparatory stub that had never needed to be completed.

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

llvm-svn: 242638

SKX supports conversion for all FP types. Integer types include doublewords and quardwords.
I added "Legal" status for these nodes and a bunch of tests.
I added "NoVLX" for AVX DAG selection to force VLX instructions selection when VLX is supported.

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

llvm-svn: 242637

llvm-svn: 242636

Summary: This patch allows executeCommand to pass a string to the processes stdin.

Reviewers: ddunbar, jroelofs

Subscribers: llvm-commits

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

llvm-svn: 242631

This was missed in D8416.

llvm-svn: 242621

No functionality change intended.

llvm-svn: 242620

llvm-svn: 242619

The standard containers are not designed to be inherited from, as
illustrated by the MSVC hacks for NodeOrdering. No functional change
intended.

llvm-svn: 242616

Demonstrates some shortfalls in subvector(cvt(x)) compared to cvt(subvector(x)) patterns - especially on AVX/AVX2 targets.

llvm-svn: 242614

llvm-svn: 242613

llvm-svn: 242610

llvm-svn: 242609

directly model in the new PM.

This also was an incredibly brittle and expensive update API that was
never fully utilized by all the passes that claimed to preserve AA, nor
could it reasonably have been extended to all of them. Any number of
places add uses of values. If we ever wanted to reliably instrument
this, we would want a callback hook much like we have with ValueHandles,
but doing this for every use addition seems *extremely* expensive in
terms of compile time.

The only user of this update mechanism is GlobalsModRef. The idea of
using this to keep it up to date doesn't really work anyways as its
analysis requires a symmetric analysis of two different memory
locations. It would be very hard to make updates be sufficiently
rigorous to *guarantee* symmetric analysis in this way, and it pretty
certainly isn't true today.

However, folks have been using GMR with this update for a long time and
seem to not be hitting the issues. The reported issue that the update
hook fixes isn't even a problem any more as other changes to
GetUnderlyingObject worked around it, and that issue stemmed from *many*
years ago. As a consequence, a prior patch provided a flag to control
the unsafe behavior of GMR, and this patch removes the update mechanism
that has questionable compile-time tradeoffs and is causing problems
with moving to the new pass manager. Note the lack of test updates --
not one test in tree actually requires this update, even for a contrived
case.

All of this was extensively discussed on the dev list, this patch will
just enact what that discussion decides on. I'm sending it for review in
part to show what I'm planning, and in part to show the *amazing* amount
of work this avoids. Every call to the AA here is something like three
to six indirect function calls, which in the non-LTO pipeline never do
any work! =[

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

llvm-svn: 242605

llvm-svn: 242596

Instrumentation and the runtime library were in disagreement about
ASan shadow offset on Android/AArch64.

This fixes a large number of existing tests on Android/AArch64.

llvm-svn: 242595

Reapply r242500 now that the swift schedmodel includes LDRLIT.

This is mostly done to disable the PostRAScheduler which optimizes for
instruction latencies which isn't a good fit for out-of-order
architectures. This also allows to leave out the itinerary table in
swift in favor of the SchedModel ones.

This change leads to performance improvements/regressions by as much as
10% in some benchmarks, in fact we loose 0.4% performance over the
llvm-testsuite for reasons that appear to be unknown or out of the
compilers control. rdar://20803802 documents the investigation of
these effects.

While it is probably a good idea to perform the same switch for the
other ARM out-of-order CPUs, I limited this change to swift as I cannot
perform the benchmark verification on the other CPUs.

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

llvm-svn: 242588

These pseudo instructions are only lowered after register allocation and
are therefore still present when the machine scheduler runs.
Add a run: line to a testcase that uses the uncommon flags necessary to
actually produce a LDRLIT instruction on swift.

llvm-svn: 242587

The idea of deferred spilling is to delay the insertion of spill code until the
very end of the allocation. A "candidate" to spill variable might not required
to be spilled because of other evictions that happened after this decision was
taken. The spirit is similar to the optimistic coloring strategy implemented in
Preston and Briggs graph coloring algorithm.

For now, this feature is highly experimental. Although correct, it would require
much more modification to properly model the effect of spilling.

Anyway, this early patch helps prototyping this feature.

Note: The test case cannot unfortunately be reduced and is probably fragile.
llvm-svn: 242585

This commit modifies the machine instruction lexer so that it now accepts the
'$' characters in identifier tokens.

This change makes the syntax for unquoted global value tokens consistent with
the syntax for the global idenfitier tokens in the LLVM's assembly language.

llvm-svn: 242584

This commit extends the interface provided by the AsmParser library by adding a
function that allows the user to parse a standalone contant value.

This change is useful for MIR serialization, as it will allow the MIR Parser to
parse the constant values in a machine constant pool.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 242579

Addition to r242510.

llvm-svn: 242561

rdar://21516488

llvm-svn: 242558

llvm-svn: 242557

This reverts commit r242500.

It broke some internal tests and Matthias asked me to revert it while he
is investigating.

llvm-svn: 242553

This error is for developers only so it makes sense to abort and get a
backtrace.

llvm-svn: 242551

This -warn-error flag invariably gets into release tarballs
and breaks builds on distributions that run tests as a part
of release process. The OCaml binding tests are especially
critical, since they often expose lingering toolchain bugs,
and so it is replaced with -w +A (equivalent to -Wall).

llvm-svn: 242550

No functional change, but it preps codegen for the future when SABSDIFF
will start getting generated in anger.

llvm-svn: 242546

No functional change, but it preps codegen for the future when SABSDIFF
will start getting generated in anger.

llvm-svn: 242545

llvm-svn: 242543

Follow-up on discussion in http://reviews.llvm.org/D11220

llvm-svn: 242542

I will send an entry in docs/CommandGuide for review today.

llvm-svn: 242533

- Changed the default FPU of cortex-m4.
- Removed "cortex-m4f" entry. Currently not supported.

Change-Id: I73121e358aa9e7ba68eb001c2143df390ff2352a
Phabricator: http://reviews.llvm.org/D11100
llvm-svn: 242528

This is mainly for the benefit of GlobalMerge, so that an alias into a
MergedGlobals variable has the same size as the original non-merged
variable.

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

llvm-svn: 242520

Summary:
Adds '--svn-path BRANCH' that causes the script to export the specified path
from each project. Otherwise the tag specified by -release, -rc, etc. will be
used. The version portion of the package name will be 'test-$path' (any forward
slashes in the branch name are replaced with underscores), for example:
  -svn-path trunk => clang+llvm-test-trunk-mips-linux-gnu.tar.xz
  -svn-path branches/release_35 => clang+llvm-test-branches_release_35-mips-linux-gnu.tar.xz

This is primarily useful for bringing new release packages up to standard
without needing to create and maintain a tag for the purpose.

Reviewers: tstellarAMD, hans

Subscribers: llvm-commits

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

llvm-svn: 242518

basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.

This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.

Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.

There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.

Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.

Also thanks to Pete and Gerolf for reviewing!

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

llvm-svn: 242512

In particular, it's much easier to read, as it doesn't expand all
the way on wide-screen displays.

CSS committed under LLVM license with explicit permission from
Daniel Bünzli <daniel.buenzli@erratique.ch>.

llvm-svn: 242511