Fix some bashims. More information on https://wiki.ubuntu.com/DashAsBinSh. Reported initially on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772302 & https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772301

llvm-svn: 227744

per-function and supports the exact desired interface.

llvm-svn: 227743

preferences interface on TTI now that all of TTI is per-function.

llvm-svn: 227741

now that we have a correct and cached subtarget specific to the
function.

Also, finish providing a cached per-function subtarget in the core
LLVMTargetMachine -- that layer hadn't switched over yet.

The only use of the TargetMachine was to re-lookup a subtarget for
a particular function to work around the fact that TTI was immutable.
Now that it is per-function and we haved a cached subtarget, use it.

This still leaves a few interfaces with real warts on them where we were
passing Function objects through the TTI interface. I'll remove these
and clean their usage up in subsequent commits now that this isn't
necessary.

llvm-svn: 227738

intermediate TTI implementation template and instead query up to the
derived class for both the TargetMachine and the TargetLowering.

Most of the derived types had a TLI cached already and there is no need
to store a less precisely typed target machine pointer.

This will in turn make it much cleaner to look up the TLI via
a per-function subtarget instead of the generic subtarget, and it will
pave the way toward pulling the subtarget used for unroll preferences
into the same form once we are *always* using the function to look up
the correct subtarget.

llvm-svn: 227737

though it was never a reasonable input.

llvm-svn: 227736

TargetIRAnalysis access path directly rather than implementing getTTI.

This even removes getTTI from the interface. It's more efficient for
each target to just register a precise callback that creates their
specific TTI.

As part of this, all of the targets which are building their subtargets
individually per-function now build their TTI instance with the function
and thus look up the correct subtarget and cache it. NVPTX, R600, and
XCore currently don't leverage this functionality, but its trivial for
them to add it now.

llvm-svn: 227735

null.

For some reason some of the original TTI code supported a null target
machine. This seems to have been legacy, and I made matters worse when
refactoring this code by spreading that pattern further through the
various targets.

The TargetMachine can't actually be null, and it doesn't make sense to
support that use case. I've now consistently removed it and removed all
of the code trying to cope with that situation. This is probably good,
as several targets *didn't* cope with it being null despite the null
default argument in their constructors. =]

llvm-svn: 227734

Brings it in line with the other hashes in EarlyCSE.

llvm-svn: 227733

This moves all of the PassManager <-> Target communication to use the
new pass manager's TargetIRAnalysis even with the old pass manager. See
the LLVM commit for some of why things are moving in this direction, but
the short version is that this will enable us to create per-function
TargetTransformInfo objects that have correct subtarget information for
that function.

llvm-svn: 227732

terms of the new pass manager's TargetIRAnalysis.

Yep, this is one of the nicer bits of the new pass manager's design.
Passes can in many cases operate in a vacuum and so we can just nest
things when convenient. This is particularly convenient here as I can
now consolidate all of the TargetMachine logic on this analysis.

The most important change here is that this pushes the function we need
TTI for all the way into the TargetMachine, and re-creates the TTI
object for each function rather than re-using it for each function.
We're now prepared to teach the targets to produce function-specific TTI
objects with specific subtargets cached, etc.

One piece of feedback I'd love here is whether its worth renaming any of
this stuff. None of the names really seem that awesome to me at this
point, but TargetTransformInfoWrapperPass is particularly ... odd.
TargetIRAnalysisWrapper might make more sense. I would want to do that
rename separately anyways, but let me know what you think.

llvm-svn: 227731

getTTI method used to get an actual TTI object.

No functionality changed. This just threads the argument and ensures
code like the inliner can correctly look up the callee's TTI rather than
using a fixed one.

The next change will use this to implement per-function subtarget usage
by TTI. The changes after that should eliminate the need for FTTI as that
will have become the default.

llvm-svn: 227730

This moves the transformation introduced in r223757 into a separate MI pass.
This allows it to cover many more cases (not only cases where there must be a 
reserved call frame), and perform rudimentary call folding. It still doesn't 
have a heuristic, so it is enabled only for optsize/minsize, with stack 
alignment <= 8, where it ought to be a fairly clear win.

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

llvm-svn: 227728

I created this header.

llvm-svn: 227727

This should be sufficient to replace the initial (minor) function pass
pipeline in Clang with the new pass manager. I'll probably add an (off
by default) flag to do that just to ensure we can get extra testing.

llvm-svn: 227726

I've added RUN lines both to the basic test for EarlyCSE and the
target-specific test, as this serves as a nice test that the TTI layer
in the new pass manager is in fact working well.

llvm-svn: 227725

over declarations.

This is both quite unproductive and causes things to crash, for example
domtree would just assert.

I've added a declaration and a domtree run to the basic high-level tests
for the new pass manager.

llvm-svn: 227724

llvm-svn: 227723

[X86] Add all intrinsics for scalar rsqrt28/rcp28 to avx512erintrin.h. Add parentheses around all macro arguments.

llvm-svn: 227722

produce it.

This adds a function to the TargetMachine that produces this analysis
via a callback for each function. This in turn faves the way to produce
a *different* TTI per-function with the correct subtarget cached.

I've also done the necessary wiring in the opt tool to thread the target
machine down and make it available to the pass registry so that we can
construct this analysis from a target machine when available.

llvm-svn: 227721

llvm-svn: 227720

llvm-svn: 227719

llvm-svn: 227718

llvm-svn: 227717

llvm-svn: 227716

live in a class.

While this isn't really significant right now, I need to expose some
state to the pass construction expressions, and making them get
evaluated within a class context is a nice way to collect members that
they may need to access.

llvm-svn: 227715

llvm-svn: 227714

[X86] Rename _mm512_valign_epi64/32 intrinsics to _mm512_alignr_epi64/32 to match Intel docs. Make immediate argument to them an ICE. Fix mask size for the alignd version.

llvm-svn: 227713

llvm-svn: 227712

This adds a test that deadstrip should preserve the section group even if there
is only one reference to a function in the group.

llvm-svn: 227711

Reported by:	shankarke

llvm-svn: 227710

This caused some tests to fail on FreeBSD, and Mac OS X.
Some std::sort() implementations will check for strict-weak-ordering
by comparing with the same element, or will compare an element to
itself for 1-element sequence. Take care of this case. Thanks to
chandlerc for explaning that to me.

Reviewed by:	ruiu

llvm-svn: 227709

Reviewed by:	shankarke, ruiu

llvm-svn: 227708

llvm-svn: 227707

The .got and .got.plt sections are already handled as typeGOT. There is no need
to handle these atoms whose contentType is typeData.

llvm-svn: 227706

llvm-svn: 227705

SeparateConstOffsetFromGEP does not change the shape of the control flow graph.

llvm-svn: 227704

Summary:
CUDA driver can unroll loops when jit-compiling PTX. To prevent CUDA
driver from unrolling a loop marked with llvm.loop.unroll.disable is not
unrolled by CUDA driver, we need to emit .pragma "nounroll" at the
header of that loop.

This patch also extracts getting unroll metadata from loop ID metadata
into a shared helper function.

Test Plan: test/CodeGen/NVPTX/nounroll.ll

Reviewers: eliben, meheff, jholewinski

Reviewed By: jholewinski

Subscribers: jholewinski, llvm-commits

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

llvm-svn: 227703

aggregate or scalar, the debug info needs to refer to the absolute offset
(relative to the entire variable) instead of storing the offset inside
the smaller aggregate.

llvm-svn: 227702

llvm-svn: 227701