uninitialized: GCC doesn't understand that the variables are only used
if !UseImm, in which case they have been initialized.

llvm-svn: 145239

Add X86 instruction selection for VPERM2I128 when AVX2 is enabled. Merge VPERMILPS/VPERMILPD detection since they are pretty similar.

llvm-svn: 145238

Some files installed by clang are not relevant for general users and we'd like
to be able to install them to a different location.  This adds a new
--with-internal-prefix configure option and a corresponding PROJ_internal_prefix
makefile variable, which defaults to the standard prefix.  A tool makefile
can specify that it should be installed to this internal prefix by defining
INTERNAL_TOOL.

llvm-svn: 145234

llc knows whether he is compiled with -DNDEBUG.
|  Optimized build with assertions.

llvm-svn: 145230

llvm-svn: 145223

lit/TestRunner.py: [Win32] Introduce WinWaitReleased(f), to wait for file handles to be released by children.

When wait() has finished, opened handles (especially writing stdout to file) might not be released immediately.
To wait for released, poll to attempt renaming.

llvm-svn: 145222

llvm-svn: 145220

llvm-svn: 145218

config.h.cmake: Synchronize to config.h.in.

llvm-svn: 145217

The config.h file's macros collide with other projects that include
LLVM and shouldn't get exported.

llvm-svn: 145215

Now that it needs to be exported in a public header (Valgrind.h)
it should be prefixed to avoid collision with other projects.
Add it to llvm-config.h as well.

This'll require regenerating the configure script after this
commit, but I don't have the required autoconf version.

llvm-svn: 145214

It was out of sync with the description in configure.ac/config.h.in.
Also re-alphabetize it from its position when it was LLVM_HOST_TRIPLE.

llvm-svn: 145213

gcc, though I thought it was older (my gcc 4.4 has it as a local patch. Whoops!)
This fixes PR10589.

Also add some debugging statements.

Remove GcnoFiles, the mapping from CompilationUnit to raw_ostream. Now that we
start by iterating over each CU and descending into them, there's no need to
maintain a mapping.

llvm-svn: 145208

llvm-svn: 145207

llvm-svn: 145206

llvm-svn: 145204

llvm-svn: 145201

llvm-svn: 145200

Merge detecting and handling for VSHUFPSY and VSHUFPDY since a lot of the code was similar for both.

llvm-svn: 145199

llvm-svn: 145198

llvm-svn: 145197

llvm-svn: 145196

fallthrough) in cases where we might fail to rotate an exit to an outer
loop onto the end of the loop chain.

Having *some* rotation, but not performing this rotation, is the primary
fix of thep performance regression with -enable-block-placement for
Olden/em3d (a whopping 30% regression). Still working on reducing the
test case that actually exercises this and the new rotation strategy out
of this code, but I want to check if this regresses other test cases
first as that may indicate it isn't the correct fix.

llvm-svn: 145195

rewrite the known problems section.  Including a short list of individual bugs per target isn't particularly useful.  Link to the target features matrix.

llvm-svn: 145193

blog'izing it.

llvm-svn: 145192

llvm-svn: 145191

llvm-svn: 145190

fails on ppc and arm hosts.

llvm-svn: 145188

was centered around the premise of laying out a loop in a chain, and
then rotating that chain. This is good for preserving contiguous layout,
but bad for actually making sane rotations. In order to keep it safe,
I had to essentially make it impossible to rotate deeply nested loops.
The information needed to correctly reason about a deeply nested loop is
actually available -- *before* we layout the loop. We know the inner
loops are already fused into chains, etc. We lose information the moment
we actually lay out the loop.

The solution was the other alternative for this algorithm I discussed
with Benjamin and some others: rather than rotating the loop
after-the-fact, try to pick a profitable starting block for the loop's
layout, and then use our existing layout logic. I was worried about the
complexity of this "pick" step, but it turns out such complexity is
needed to handle all the important cases I keep teasing out of benchmarks.

This is, I'm afraid, a bit of a work-in-progress. It is still
misbehaving on some likely important cases I'm investigating in Olden.
It also isn't really tested. I'm going to try to craft some interesting
nested-loop test cases, but it's likely to be extremely time consuming
and I don't want to go there until I'm sure I'm testing the correct
behavior. Sadly I can't come up with a way of getting simple, fine
grained test cases for this logic. We need complex loop structures to
even trigger much of it.

llvm-svn: 145183

Original commit message:
Fixed ObjectFile functions:
- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.

llvm-svn: 145182

llvm-svn: 145181

- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.

llvm-svn: 145180

heavily on AnalyzeBranch. That routine doesn't behave as we want given
that rotation occurs mid-way through re-ordering the function. Instead
merely check that there are not unanalyzable branching constructs
present, and then reason about the CFG via successor lists. This
actually simplifies my mental model for all of this as well.

The concrete result is that we now will rotate more loop chains. I've
added a test case from Olden highlighting the effect. There is still
a bit more to do here though in order to regain all of the performance
in Olden.

llvm-svn: 145179

that mainline needs no autoupgrade logic for intrinsics yet, woohoo!

llvm-svn: 145178

I'll work on turning this into something intelligible tomorrow.

llvm-svn: 145177

autoupgrade logic for 2.9 and before.

llvm-svn: 145176

trampoline forms.  Both of these were correct in LLVM 3.0, and we don't
need to support LLVM 2.9 and earlier in mainline.

llvm-svn: 145174

llvm-svn: 145173

remove asmparsing and documentation support for "volatile load", which was only produced by LLVM 2.9 and earlier.  LLVM 3.0 and later prefers "load volatile".

llvm-svn: 145172

Upgrade syntax of tests using volatile instructions to use 'load volatile' instead of 'volatile load', which is archaic.

llvm-svn: 145171