Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239899

Summary:
Previously, MCSymbolRefExpr::create() was called with a StringRef of the symbol
name, which it would then search for in the Symbols StringMap (from MCContext).

However, relative labels (which are temporary symbols) are apparently not stored
in the Symbols StringMap, so we end up creating a new {$,.L}tmp symbol
({$,.L}tmp00, {$,.L}tmp10 etc.) each time we create an MCSymbolRefExpr by
passing in the symbol name as a StringRef.

Fortunately, there is a version of MCSymbolRefExpr::create() which takes an
MCSymbol* and we already have an MCSymbol* at that point, so we can just pass
that in instead of the StringRef.

I also removed the local StringRef calls to MCSymbolRefExpr::create() from
expandMemInst(), as those cases can be handled by evaluateRelocExpr() anyway.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239897

Change builtin function name and signature ( add third parameter - rounding mode ).
Added tests for intrinsics.

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

llvm-svn: 239888

names for counts with the word 'Count' to make them less ambiguous.

This will be an actual error if we use unscoped enums for any of these,
and generally this seems much clearer to read.

Also, use clang-format to normalize the formatting of this code which
seems to have been needlessly odd.

No functionality changed here.

llvm-svn: 239887

This is now living in MemoryLocation, which is what it pertains to. It
is also an enum there rather than a static data member which is left
never defined.

llvm-svn: 239886

that it is its own entity in the form of MemoryLocation, and update all
the callers.

This is an entirely mechanical change. References to "Location" within
AA subclases become "MemoryLocation", and elsewhere
"AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps
out-of-tree folks update.

llvm-svn: 239885

virtual interface on AliasAnalysis only deals with ModRef information.

This interface was both computing memory locations by using TLI and
other tricks to estimate the size of memory referenced by an operand,
and computing ModRef information through similar investigations. This
change narrows the scope of the virtual interface on AliasAnalysis
slightly.

Note that all of this code could live in BasicAA, and be done with
a single investigation of the argument, if it weren't for the fact that
the generic code in AliasAnalysis::getModRefBehavior for a callsite
calls into the virtual aspect of (now) getArgModRefInfo. But this
patch's arrangement seems a not terrible way to go for now.

The other interesting wrinkle is how we could reasonably extend LLVM
with support for custom memory location sizes and mod/ref behavior for
library routines. After discussions with Hal on the review, the
conclusion is that this would be best done by fleshing out the much
desired support for extensions to TLI, and support these types of
queries in that interface where we would likely be doing other library
API recognition and analysis.

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

llvm-svn: 239884

The patch triggers a miscompile on SPEC 2006 403.gcc with the (ref)
200.i and scilab.i inputs. I opened PR23866 to track analysis of this.

This reverts commit r238793.

llvm-svn: 239880

llvm-svn: 239877

[Hexagon] Adding MC ELF streamer and updating addend relocation test which shows correct ELF symbol.

llvm-svn: 239876

Adds static_asserts to ensure alignment of concatenated objects is
correct, and fixes them where they are not.

Also changes the definition of AlignOf to use constexpr, except on
MSVC, to avoid enum comparison warnings from GCC.

(There's not too much of this in llvm itself, most of the fun is in
clang).

This seems to make LLVM actually work without Bus Error on 32bit
sparc.

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

llvm-svn: 239872

Without this the included unit test would assert in

  assert(BasicBlockFwdRefs.empty() && "Unresolved blockaddress fwd references");

llvm-svn: 239871

This just handles both cases in the same place.

Extracted from a patch by Karl Schimpf.

llvm-svn: 239870

We were already deleting it, this just makes it explicit.

llvm-svn: 239867

Different object formats represent references from dwarf in different ways.

ELF uses a relocation to the referenced point (except for .dwo) and
COFF/MachO use the offset of the referenced point inside its section.

This patch renames emitSectionOffset because

* It doesn't produce an offset on ELF.
* It changes behavior depending on how DWARF is represented, so adding
dwarf to its name is probably a good thing.

The patch also adds an option to force the use of offsets.That avoids
funny looking code like

  if (!UseOffsets)
    Asm->emitSectionOffset....

It was correct, but read as if the ! was inverted.

llvm-svn: 239866

Moved RecurrenceInstDesc into RecurrenceDescriptor to simplify the namespaces.

llvm-svn: 239862

These were originally added in r227242,
but that patch was reverted because it
caused a failure on AArch64.

llvm-svn: 239860

llvm-svn: 239858

llvm-svn: 239856

This patch enables support for the conversion of v2i32 to v2f64 to use the CVTDQ2PD xmm instruction and stay on the SSE unit instead of scalarizing, sign extending to i64 and using CVTSI2SDQ scalar conversions.

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

llvm-svn: 239855

...because I see 'StoreBW' and read it as 'store bandwidth'

llvm-svn: 239850

The original change broke clang side tests.  I will be submitting those momentarily.  This change includes post commit feedback on the original change from from Pete Cooper.

Original Submission comments:
If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129.

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

llvm-svn: 239849

llvm-svn: 239847

Before this patch the bitcode reader would read a module from a file
that contained in order:

* Any number of non MODULE_BLOCK sub blocks.
* One MODULE_BLOCK
* Any number of non MODULE_BLOCK sub blocks.
* 4 '\n' characters to handle OS X's ranlib.

Since we support lazy reading of modules, any information that is relevant
for the module has to be in the MODULE_BLOCK or before it. We don't gain
anything from checking what is after.

This patch then changes the reader to stop once the MODULE_BLOCK has been
successfully parsed.

This avoids the ugly special case for .bc files in an archive and makes it
easier to embed bitcode files.

llvm-svn: 239845

Summary:
When propagating mass through irregular loops, the mass flowing through
each loop header may not be equal. This was causing wrong frequencies
to be computed for irregular loop headers.

Fixed by keeping track of masses flowing through each of the headers in
an irregular loop. To do this, we now keep track of per-header backedge
weights. After the loop mass is distributed through the loop, the
backedge weights are used to re-distribute the loop mass to the loop
headers.

Since each backedge will have a mass proportional to the different
branch weights, the loop headers will end up with a more approximate
weight distribution (as opposed to the current distribution that assumes
that every loop header is the same).

Reviewers: dexonsmith

Subscribers: llvm-commits

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

llvm-svn: 239843

[Statepoints] Test only change. Check that statepoint lowering didn't generate more than expected amount of spills.
See http://reviews.llvm.org/D10402 for related discussion.

llvm-svn: 239842

While completely undefined registers are easy to catch and get their
<undef> flag early in ProcessImplicitDefs/RegisterCoalescer reading from
a partially defined register where just the subreg happens to be
undefined is harder to catch so we only add the undef flag in the
virtual register rewriting step.

No testcase as I cannot reproduce the problem on any of the in-tree targets at
the moment.

This fixes rdar://21387089

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

llvm-svn: 239838

LaneMasks as given by getSubRegIndexLaneMask() have a limited number of
of bits, so for targets with more than 31 disjunct subregister there may
be cases where:

   getSubReg(Reg,A) does not overlap getSubReg(Reg,B)

but we still have

   (getSubRegIndexLaneMask(A) & getSubRegIndexLaneMask(B)) != 0.

I had hoped to keep this an implementation detail of the tablegen but as
my next commit shows we can avoid unnecessary imp-defs operands if we
know that the lane masks in use are precise.

This is in preparation to http://reviews.llvm.org/D10470.

llvm-svn: 239837

Old names, new names, and what they really mean:

- IsWin64 -> IsWin64CC: This is true on non-Windows x86_64 platforms
  when the ms_abi calling convention is used.
- IsWinEH -> IsWin64Prologue: True when the target is Win64, regardless
  of calling convention. Changes the prologue to obey the constraints of
  the Win64 unwinder.
- NeedsWinEH -> NeedsWinCFI: We're using the win64 prologue *and* the we
  want .xdata unwind tables. Analogous to NeedsDwarfCFI.

NFC

llvm-svn: 239836

A reduction is a special kind of recurrence. In the loop vectorizer we currently
identify basic reductions. Future patches will extend this to identifying basic
recurrences.

llvm-svn: 239835

llvm-svn: 239833

This commit reports an error when a machine function from a MIR file that contains
LLVM IR can't find a function with the same name in the loaded LLVM IR module.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 239831

llvm-svn: 239829

This is an updated version of the patch that was checked in at:
http://reviews.llvm.org/rL237046

but subsequently reverted because it exposed a bug in the DAG Combiner:
http://reviews.llvm.org/D9893

This time, there's an enablement flag ("EnableFMFInDAG") around the code in
SelectionDAGBuilder where we copy the set of FP optimization flags from IR
instructions to DAG nodes. So, in theory, there should be no functional change
from this patch as-is, but it will allow testing with the added functionality
to proceed via "-enable-fmf-dag" passed to llc.

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

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

llvm-svn: 239828

The mftb instruction was incorrectly marked as deprecated in the PPC
Backend. Instead, it should not be treated as deprecated, but rather be
implemented using the mfspr instruction. A similar patch was put into GCC last
year. Details can be found at:

https://sourceware.org/ml/binutils/2014-11/msg00383.html.
This change will replace instances of the mftb instruction with the mfspr
instruction for all CPUs except 601 and pwr3. This will also be the default
behaviour.

Additional details can be found in:

https://llvm.org/bugs/show_bug.cgi?id=23680

Phabricator review: http://reviews.llvm.org/D10419

llvm-svn: 239827

llvm-svn: 239826

Reapply r239539. Don't assume the collected number of
stores is the same vector size. Just take the first N
stores to fill the vector.

llvm-svn: 239825

Summary:

Reviewers: rengolin

Reviewed By: rengolin

Subscribers: llvm-commits, rengolin, jholewinski

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

llvm-svn: 239823

Any combination of +-inf/+-inf is NaN so it's already ignored with
nnan and we can skip checking for ninf. Also rephrase logic in comments
a bit.

llvm-svn: 239821

The cmake check for whether libatomic could be used had been
unconditionally setting the result to false. Which was somewhat
fortunate, because the prerequisite check for whether it was *needed*
was always claiming it was, even if it was not.

However, this made platforms where libatomic is actually necessary
fail to link.

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

llvm-svn: 239819