llvm-svn: 177620

llvm-svn: 177600

When computing the demanded bits of Load SDNodes, make sure that we are looking at the loaded-value operand and not the ptr result (in case of pre-inc loads).
rdar://13348420

llvm-svn: 177596

This reverts commit 06091513c283c863296f01cc7c2e86b56bb50d02.

The code is obviously wrong, but the trivial fix causes
inefficient code generation on X86. Somebody with more
knowledge of the code needs to take a look here.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 177529

case of order propagation during isel.

Thanks Owen for the suggestion!

llvm-svn: 177525

TargetOpcodes need to be treaded as Machine- and not ISD-Opcodes.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 177518

A node's ordering is only propagated during legalization if (a) the new node does
not have an ordering (is not a CSE'd node), or (b) the new node has an ordering
that is higher than the node being legalized.

llvm-svn: 177465

Also remove unneeded #include and forward declaration.

llvm-svn: 177357

llvm-svn: 177356

The always-true "(int)Int == (signed)Int" comparison was found
while experimenting with a potential new Clang warning.

llvm-svn: 177290

The linker sorts the .tls$<xyz> sections by name, and we need
to make sure any extra sections we produce (e.g. for weak globals) 
always end up between .tls$AAA and .tls$ZZZ, even if the name 
starts with e.g. an underscore.

Patch by David Nadlinger!

llvm-svn: 177256

Implicit defs are not currently positional and not modeled by the
per-operand machine model. Unfortunately, we treat defs that are part
of the architectural instruction description, like flags, the same as
other implicit defs. Really, they should have a fixed MachineInstr
layout and probably shouldn't be "implicit" at all.

For now, we'll change the default latency to be the max operand
latency. That will give flag setting operands full latency for x86
folded loads. Other kinds of "fake" implicit defs don't occur prior to
regalloc anyway, and we would like them to go away postRegAlloc as
well.

llvm-svn: 177227

This is a generic function (derived from PEI); moving it into
MachineFrameInfo eliminates a current redundancy between the ARM and AArch64
backends, and will allow it to be used by the PowerPC target code.

No functionality change intended.

llvm-svn: 177111

Add the current PEI register scavenger as a parameter to the
processFunctionBeforeFrameFinalized callback.

This change is necessary in order to allow the PowerPC target code to
set the register scavenger frame index after the save-area offset
adjustments performed by processFunctionBeforeFrameFinalized. Only
after these adjustments have been made is it possible to estimate
the size of the stack frame.

llvm-svn: 177108

This doesn't reset all of the target options within the TargetOptions
object. This is because some of those are ABI-specific and must be determined if
it's okay to change those on the fly.

llvm-svn: 176986

llvm-svn: 176963

llvm-svn: 176962

We have the same assertion in createVirtualRegister.

llvm-svn: 176959

belongs to a different compile unit.

DW_FORM_ref_addr should be used for cross compile-unit reference.

When compiling a large application, we got a dwarfdump verification error where
abstract_origin points to nowhere.

This error can't be reproduced on any testing case in MultiSource.
We may have other cases where we use DW_FORM_ref4 unconditionally.

rdar://problem/13370501

llvm-svn: 176882

llvm-svn: 176881

Versioned debug info support has been a burden to maintain & also compromised
current debug info verification by causing test cases testing old debug info to
remain rather than being updated to the latest. It also makes it hard to add or
change the metadata schema by requiring various backwards-compatibility in the
DI* hierarchy.

So it's being removed in preparation for new changes to the schema to tidy up
old/unnecessary fields and add new fields needed for new debug info (well, new
to LLVM at least).

The more surprising part of this is the changes to DI*::Verify - this became
necessary due to the changes to AsmWriter. AsmWriter was relying on the version
test to decide which bits of metadata were actually debug info when printing
the comment annotations. Without the version information the tag numbers were
too common & it would print debug info on random metadata that happened to
start with an integer that matched a tag number. Instead this change makes the
Verify functions more precise (just adding "number of operands" checks - not
type checking those operands yet) & relies on that to decide which metadata is
debug info metadata.

llvm-svn: 176838

lower an expect intrinsic that is a constant expression.

llvm-svn: 176830

llvm-svn: 176787

PHIs are allowed to have multiple operand pairs per predecessor, and
this code works just fine when it happens.

llvm-svn: 176734

Summary:
Statistics are still available in Release+Asserts (any +Asserts builds),
and stats can also be turned on with LLVM_ENABLE_STATS.

Move some of the FastISel stats that were moved under DEBUG()
back out of DEBUG(), since stats are disabled across the board now.

Many tests depend on grepping "-stats" output.  Move those into
a orig_dir/Stats/. so that they can be marked as unsupported
when building without statistics.

Differential Revision: http://llvm-reviews.chandlerc.com/D486

llvm-svn: 176733

To find the last use of a register unit, start from the bottom and scan
upwards until a user is found.

<rdar://problem/13353090>

llvm-svn: 176706

llvm-svn: 176703

llvm-svn: 176695

LegalizeDAG.cpp uses the value of the comparison operands when checking
the legality of BR_CC, so DAGCombiner should do the same.

v2:
  - Expand more BR_CC value types for NVPTX

v3:
  - Expand correct BR_CC value types for Hexagon, Mips, and XCore.

llvm-svn: 176694

This verifies live intervals both before and after scheduling. It's
useful for anyone hacking on live interval update.

Note that we don't yet pass verification all the time. We don't yet
handle updating nonallocatable live intervals perfectly.

llvm-svn: 176685

Code generation makes some basic assumptions about the IR it's been given. In
particular, if there is only one 'invoke' in the function, then that invoke
won't be going away. However, with the advent of the `llvm.donothing' intrinsic,
those invokes may go away. If all of them go away, the landing pad no longer has
any users. This confuses the back-end, which asserts.

This happens with SjLj exceptions, because that's the model that modifies the IR
based on there being invokes, etc. in the function.

Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will
give us a CFG that the back-end won't be confused about. If all of the invokes
in a function are removed, then the SjLj EH prepare pass won't insert the bogus
code the relies upon the invokes being there.
<rdar://problem/13228754&13316637>

llvm-svn: 176677

llvm-svn: 176669

In very rare cases caused by irreducible control flow, the dominating
block can have the same trace head without actually being part of the
trace.

As long as such a dominator still has valid instruction depths, it is OK
to use it for computing instruction depths.

Rename the function to avoid lying, and add a check that instruction
depths are computed for the dominator.

llvm-svn: 176668

rdar://13370942

llvm-svn: 176659

rdar://13370942

llvm-svn: 176649

llvm-svn: 176648

llvm-svn: 176638

rdar:13370002 [pre-RA-sched] assertion: released too many times

I tracked this down to an earlier hack that is no longer applicable
and interfered with normal scheduler logic. With the changes in
r176037, it was causing an instruction to be scheduled multiple times.

I have an external test case that I tried hard to reduce and
failed. I can't even reproduce with llc.

llvm-svn: 176636

llvm-svn: 176615

Just scalarize the element and rebuild a vector of the result type
from that.

rdar://13281568

llvm-svn: 176614