Please update also Other/link-opts.ll, in next time.

llvm-svn: 199197

llvm-svn: 199194

Separate the concept of 16-bit/32-bit operand size controlled by 0x66 prefix and the current mode from the concept of SSE instructions using 0x66 prefix as part of their encoding without being affected by the mode.

This should allow SSE instructions to be encoded correctly in 16-bit mode which r198586 probably broke.

llvm-svn: 199193

Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.

This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker.  This puts the onus on the
linker to decide whether (and what) to internalize.

In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.

This patch enables three strategies:

- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
  visibility.

LTO_INTERNALIZE_FULL should be used when linking an executable.

Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized.  E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise.  However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.

lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().

<rdar://problem/14334895>

llvm-svn: 199191

When creating a virtual register for a def, the value type should be
used to pick the register class. If we only use the register class
constraint on the instruction, we might pick a too large register class.

Some registers can store values of different sizes. For example, the x86
xmm registers can hold f32, f64, and 128-bit vectors. The three
different value sizes are represented by register classes with identical
register sets: FR32, FR64, and VR128. These register classes have
different spill slot sizes, so it is important to use the right one.

The register class constraint on an instruction doesn't necessarily care
about the size of the value its defining. The value type determines
that.

This fixes a problem where InstrEmitter was picking 32-bit register
classes for 64-bit values on SPARC.

llvm-svn: 199187

The already allocatable DPair superclass contains odd-even D register
pair in addition to the even-odd pairs in the QPR register class. There
is no reason to constrain the set of D register pairs that can be used
for NEON values. Any NEON instructions that require a Q register will
automatically constrain the register class to QPR.

The allocation order for DPair begins with the QPR registers, so
register allocation is unlikely to change much.

llvm-svn: 199186

llvm-svn: 199185

llvm-svn: 199183

requires Clang 3.1 or GCC 4.7. If the compiler isn't Clang or GCC, we
don't try to do any sanity checking, but this give us at least
a reasonable baseline of modern compilers.

Also, I'm not claiming that this is the best way to do compiler version
tests. I'm happy for anyone to suggest better ways of doing this test.

llvm-svn: 199182

This matches what gnu as does and implementing this is easier than arguing
about it.

llvm-svn: 199181

We need to ensure that StackSlotColoring.cpp does not reuse stack
spill slots in functions that call "returns_twice" functions such as
setjmp(), otherwise this can lead to miscompiled code, because a stack
slot would be clobbered when it's still live.

This was already handled correctly for functions that call setjmp()
(though this wasn't covered by a test), but not for functions that
invoke setjmp().

We fix this by changing callsFunctionThatReturnsTwice() to check for
invoke instructions.

This fixes PR18244.

llvm-svn: 199180

Also, so is stacker, llvm-tv, etc. Wow.

But will someone please fess up to what projects/privbracket is and why
our autoconf build supports it?

llvm-svn: 199179

llvm-svn: 199178

This will allow it to be called from target independent parts of the main
streamer that don't know if there is a registered target streamer or not. This
in turn will allow targets to perform extra actions at specified points in the
interface: add extra flags for some labels, extra work during finalization, etc.

llvm-svn: 199174

llvm-svn: 199162

llvm-svn: 199158

option with the others in the top level CMakeLists, and put the check in
HandleLLVMOptions. This will also let it be used from the standalone
Clang builds.

llvm-svn: 199149

compiler version checking doesn't work on 2.8.7. This feature was
documented in 2.8.10, but existed for an unknown amount of time before
that.

I'm actually happy to revert this and remove the use of the feature if
there is anyone with a specific problem updating CMake. Please just let
me know. I don't want to re-implement this CMake functionality unless
there is a reason, and this is the only real way to find that out.

llvm-svn: 199148

llvm-svn: 199147

llvm-svn: 199146

likely to be reverted and re-applied a few times. The minimum versions
we're aiming at:

  GCC 4.7
  Clang 3.1
  MSVC 17.0 (Visual Studio 2012)

Let me know if something breaks!

llvm-svn: 199145

This commit teaches DAG to reassociate vector ops, which in turn enables
constant folding of vector op chains that appear later on during custom lowering
and DAG combine.

Reviewed by Andrea Di Biagio

llvm-svn: 199135

This is a very confusing option for a feature that will go away.

-enable-misched is exposed instead to help triage issues with the new
scheduler.

llvm-svn: 199133

The issue is caused when Post-RA scheduler reorders a bundle instruction
(IT block). However, it only flips the CPSR liveness of the bundle instruction,
leaves the instructions inside the bundle unchanged, which causes inconstancy and crashes
Thumb2SizeReduction.cpp::ReduceMBB().

llvm-svn: 199127

llvm-svn: 199125

APInt only knows how to compare values with the same BitWidth and asserts
in all other cases.

With this fix, function PerformORCombine does not use the APInt equality
operator if the APInt values returned by 'isConstantSplat' differ in BitWidth.
In that case they are different and no comparison is needed.

llvm-svn: 199119

llvm-svn: 199118

...so that it does something vaguely sensible.

llvm-svn: 199117

llvm-svn: 199116

The old mask in f24 wasn't well chosen because the lshr would always be zero.
CodeGen didn't detect this but InstCombine would.  The new mask ensures
that both shifts are needed.

f26 is specifically testing for a wrap-around mask.  The AND can be applied
to just the shift left, either before or after the shift.  Again, CodeGen
kept it in the original form but InstCombine would mask after the shift
instead.  The exact choice of NILF isn't important for the test so I just
dropped it and kept the rotate.

llvm-svn: 199115

...into (ashr (shl (anyext X), ...), ...), which requires one fewer
instruction.  The (anyext X) can sometimes be simplified too.

I didn't do this in DAGCombiner because widening shifts isn't a win
on all targets.

llvm-svn: 199114

llvm-svn: 199113

rdar://problem/15800156

llvm-svn: 199109

Previously we only used GPR for the destination placeholder in "ldr rD, [pc,
incorrect codegen under the integrated assembler.

This should fix both issues (which probably only affect MachO targets at the
moment).

rdar://problem/15800156

llvm-svn: 199108

This finishes the job started in r198756, and creates separate opcodes for
64-bit vs. 32-bit versions of the rest of the RET instructions too.

LRETL/LRETQ are interesting... I can't see any justification for their
existence in the SDM. There should be no 'LRETL' in 64-bit mode, and no
need for a REX.W prefix for LRETQ. But this is what GAS does, and my
Sandybridge CPU and an Opteron 6376 concur when tested as follows:

asm __volatile__("pushq $0x1234\nmovq $0x33,%rax\nsalq $32,%rax\norq $1f,%rax\npushq %rax\nlretl $8\n1:");
asm __volatile__("pushq $1234\npushq $0x33\npushq $1f\nlretq $8\n1:");
asm __volatile__("pushq $0x33\npushq $1f\nlretq\n1:");
asm __volatile__("pushq $0x1234\npushq $0x33\npushq $1f\nlretq $8\n1:");

cf. PR8592 and commit r118903, which added LRETQ. I only added LRETIQ to
match it.

I don't quite understand how the Intel syntax parsing for ret
instructions is working, despite r154468 allegedly fixing it. Aren't the
explicitly sized 'retw', 'retd' and 'retq' supposed to work? I have at
least made the 'lretq' work with (and indeed *require*) the 'q'.

llvm-svn: 199106

can be used by both the new pass manager and the old.

This removes it from any of the virtual mess of the pass interfaces and
lets it derive cleanly from the DominatorTreeBase<> template. In turn,
tons of boilerplate interface can be nuked and it turns into a very
straightforward extension of the base DominatorTree interface.

The old analysis pass is now a simple wrapper. The names and style of
this split should match the split between CallGraph and
CallGraphWrapperPass. All of the users of DominatorTree have been
updated to match using many of the same tricks as with CallGraph. The
goal is that the common type remains the resulting DominatorTree rather
than the pass. This will make subsequent work toward the new pass
manager significantly easier.

Also in numerous places things became cleaner because I switched from
re-running the pass (!!! mid way through some other passes run!!!) to
directly recomputing the domtree.

llvm-svn: 199104

This is a precursor to breaking the pass that computes the DominatorTree
apart from the concrete DominatorTree.

llvm-svn: 199103

Changed intrinsics for vrcp14/vrcp28 vrsqrt14/vrsqrt28 - aligned with GCC.

llvm-svn: 199102

support notionally const queries even though they may trigger DFS
numbering updates.

The updating of DFS numbers and tracking of slow queries do not mutate
the observable state of the domtree. They should be const to
differentiate them from the APIs which mutate the tree directly to do
incremental updates.

This will make it possible in a world where the DominatorTree is not
a pass but merely the result of running a pass to derive DominatorTree
from the base class as it was originally designed, removing a huge
duplication of API in DominatorTree.

llvm-svn: 199101

trees into the Support library.

These are all expressed in terms of the generic GraphTraits and CFG,
with no reliance on any concrete IR types. Putting them in support
clarifies that and makes the fact that the static analyzer in Clang uses
them much more sane. When moving the Dominators.h file into the IR
library I claimed that this was the right home for it but not something
I planned to work on. Oops.

So why am I doing this? It happens to be one step toward breaking the
requirement that IR verification can only be performed from inside of
a pass context, which completely blocks the implementation of
verification for the new pass manager infrastructure. Fixing it will
also allow removing the concept of the "preverify" step (WTF???) and
allow the verifier to cleanly flag functions which fail verification in
a way that precludes even computing dominance information. Currently,
that results in a fatal error even when you ask the verifier to not
fatally error. It's awesome like that.

The yak shaving will continue...

llvm-svn: 199095