MF is normally initialized in AsmPrinter::SetupMachineFunction, but if the file
contains only globals (no functions), then we need this to be initialized
because, when encountering an error, lowerConstant() references it.

This should fix the non-deterministic failures of
test/CodeGen/X86/nonconst-static-iv.ll, etc.

llvm-svn: 186068

When computing currently-live registers, the register scavenger excludes undef
uses. As a result, undef uses are ignored when computing the restore points of
registers spilled into the emergency slots. While the register scavenger
normally excludes from consideration, when scavenging, registers used by the
current instruction, we need to not exclude undef uses. Otherwise, we might end
up requiring more emergency spill slots than we have (in the case where the
undef use *is* the currently-spilled register).

Another bug found by llvm-stress.

llvm-svn: 186067

llvm-svn: 186065

llvm-svn: 186064

SLPVectorizer: refactor the code that places extracts. Place the code that decides where to put extracts in the build-tree phase. This allows us to take the cost of the extracts into account.

llvm-svn: 186058

Without the changes introduced into this patch, if TRE saw any allocas at all,
TRE would not perform TRE *or* mark callsites with the tail marker.

Because TRE runs after mem2reg, this inadequacy is not a death sentence. But
given a callsite A without escaping alloca argument, A may not be able to have
the tail marker placed on it due to a separate callsite B having a write-back
parameter passed in via an argument with the nocapture attribute.

Assume that B is the only other callsite besides A and B only has nocapture
escaping alloca arguments (*NOTE* B may have other arguments that are not passed
allocas). In this case not marking A with the tail marker is unnecessarily
conservative since:

  1. By assumption A has no escaping alloca arguments itself so it can not
     access the caller's stack via its arguments.

  2. Since all of B's escaping alloca arguments are passed as parameters with
     the nocapture attribute, we know that B does not stash said escaping
     allocas in a manner that outlives B itself and thus could be accessed
     indirectly by A.

With the changes introduced by this patch:

  1. If we see any escaping allocas passed as a capturing argument, we do
     nothing and bail early.

  2. If we do not see any escaping allocas passed as captured arguments but we
     do see escaping allocas passed as nocapture arguments:

       i. We do not perform TRE to avoid PR962 since the code generator produces
          significantly worse code for the dynamic allocas that would be created
          by the TRE algorithm.

       ii. If we do not return twice, mark call sites without escaping allocas
           with the tail marker. *NOTE* This excludes functions with escaping
           nocapture allocas.

  3. If we do not see any escaping allocas at all (whether captured or not):

       i. If we do not have usage of setjmp, mark all callsites with the tail
          marker.

       ii. If there are no dynamic/variable sized allocas in the function,
           attempt to perform TRE on all callsites in the function.

Based off of a patch by Nick Lewycky.

rdar://14324281.

llvm-svn: 186057

A non-constant-foldable static initializer expression containing insertvalue or
extractvalue had been causing an assert:

  Constants.cpp:1971: Assertion `FC && "ExtractValue constant expr couldn't be
                                 folded!"' failed.

Now we report a more-sensible "Unsupported expression in static initializer"
error instead.

Fixes PR15417.

llvm-svn: 186044

llvm-svn: 186041

Patch from Игорь Пашев  (I do hope we support utf-8 commit messages; I
also hope he'll forgive me for transliterating it as Igor Pashev in
case things go horribly wrong).

llvm-svn: 186034

llvm-svn: 186032

llvm-svn: 186029

[objc-arc] Changed 'mode: c++' => 'C++' at Nick Lewycky's suggestion. Also removed unnecessary mode: c++ lines from .cpp files.

llvm-svn: 186026

llvm-svn: 186018

llvm-svn: 186017

The status function is already using a syscall that returns the file size.
Remember it and implement file_size as a simple wrapper.

No functionally change, but clients that already use status now can avoid
calling file_size.

llvm-svn: 186016

llvm-svn: 186015

llvm-svn: 186014

llvm-svn: 186013

Enough for the radeonsi driver to use it for calculating derivatives.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186012

lit test coverage to follow in the next commit.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186011

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186010

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186009

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186008

In discussing this change with Bill Schmidt, it was decided that the original
comment about negative FIs was incorrect. We'll still exclude them for now, but
now with a more-accurate explanation.

llvm-svn: 186005

llvm-svn: 186000

llvm-svn: 185999

llvm-svn: 185995

Currently ARM is the only backend that supports FMA instructions (for at least some subtargets) but does not implement this virtual, so FMAs are never generated except from explicit fma intrinsic calls. Apparently this is due to the fact that it supports both fused (one rounding step) and unfused (two rounding step) multiply + add instructions. This patch clarifies that this the case without changing behavior by implementing the virtual function to simply return false, as the default TargetLoweringBase version does.

It is possible that some cpus perform the fused version faster than the unfused version and vice-versa, so the function implementation should be revisited if hard data is found.

llvm-svn: 185994

Pulled in a testcase from the debuginfo-test suite.

llvm-svn: 185993

llvm-svn: 185992

llvm-svn: 185984

Propagate the fix from r185712 to Thumb2 codegen as well. Original
commit message applies here as well:

A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and
packs them in the bottom half of "x". An arithmetic and logic shift are
only equivalent in this context if the shift amount is 16. We would be
shifting in ones into the bottom 16bits instead of zeros if "y" is
negative.

rdar://14338767

llvm-svn: 185982

A special case list can now specify categories for specific globals,
which can be used to instruct an instrumentation pass to treat certain
functions or global variables in a specific way, such as by omitting
certain aspects of instrumentation while keeping others, or informing
the instrumentation pass that a specific uninstrumentable function
has certain semantics, thus allowing the pass to instrument callers
according to those semantics.

For example, AddressSanitizer now uses the "init" category instead of
global-init prefixes for globals whose initializers should not be
instrumented, but which in all other respects should be instrumented.

The motivating use case is DataFlowSanitizer, which will have a
number of different categories for uninstrumentable functions, such
as "functional" which specifies that a function has pure functional
semantics, or "discard" which indicates that a function's return
value should not be labelled.

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

llvm-svn: 185978

it more unit testable, and fix memory leak in the other ctor.

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

llvm-svn: 185976

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

llvm-svn: 185975

llvm-svn: 185973

llvm-svn: 185971

Fix PR16571, which is a bug in the code that checks that all of the types in the bundle are uniform.

llvm-svn: 185970

Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old convention was that a DBG_VALUE is a register-indirect value if
the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE
is register-indirect if the first operand is a register and the second
operand is an immediate. For plain register values the combination reg,
reg is used. MachineInstrBuilder::BuildMI knows how to build the new
DBG_VALUES.

rdar://problem/13658587

llvm-svn: 185966

Because integer BUILD_VECTOR operands may have a larger type than the result's
vector element type, and all operands must have the same type, when widening a
BUILD_VECTOR node by adding UNDEFs, we cannot use the vector element type, but
rather must use the type of the existing operands.

Another bug found by llvm-stress.

llvm-svn: 185960