llvm-svn: 255027

llvm-svn: 255021

Summary:

Reviewers: vkalintiris

Subscribers: llvm-commits, dsanders

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

llvm-svn: 255018

Summary:
We don't check the size operand on ext/dext*/ins/dins* yet because the
permitted range depends on the pos argument and we can't check that using
this mechanism.

The bug was that dextu/dinsu accepted 0..31 in the pos operand instead of 32..63.

Reviewers: vkalintiris

Subscribers: llvm-commits, dsanders

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

llvm-svn: 255015

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

llvm-svn: 255011

ARMv8.2-A adds 16-bit floating point versions of all existing SIMD
floating-point instructions. This is an optional extension, so all of
these instructions require the FeatureFullFP16 subtarget feature.

Note that VFP without SIMD is not a valid combination for any version of
ARMv8-A, but I have ensured that these instructions all depend on both
FeatureNEON and FeatureFullFP16 for consistency.

The ".2h" vector type specifier is now legal (for the scalar pairwise
reduction instructions), so some unrelated tests have been modified as
different error messages are emitted. This is not a problem as the
invalid operands are still caught.

llvm-svn: 255010

continue of Wrong FNSTSW size operator
url: http://reviews.llvm.org/D14953


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

llvm-svn: 255007

Reduces the scope over which the struct is visible, making its usages
obvious.  I did not move structs in cases where this wasn't a clear
win (the struct is too large, or is grouped in some other interesting
way).

llvm-svn: 255003

llvm-svn: 255002

The StringRef constructor is unnecessary (since we're converting to
std::string anyway), and having it requires an explicit call to
StringRef's or std::string's constructor.

llvm-svn: 255000

llvm-svn: 254999

llvm-svn: 254998

llvm-svn: 254997

llvm-svn: 254996

llvm-svn: 254995

llvm-svn: 254994

The default implementation in BasicTTI already checks TLI and does
the right thing.

llvm-svn: 254993

Currently, vectors of halfs end up as ConstantVectors, but there isn't
a good reason they can't be ConstantDataVectors. This should save some
memory.

llvm-svn: 254991

Use the appropriate helper instead.

llvm-svn: 254990

llvm-svn: 254989

It's strange to duplicate the logic for emitting FP values into
emitGlobalConstantDataSequential, and it's even stranger that we end
up printing the verbose assembly comments differently between the two
paths. Just call into emitGlobalConstantFP rather than crudely
duplicating its logic.

llvm-svn: 254988

llvm-svn: 254987

rdar://9001553

llvm-svn: 254978

Summary:
Also add a stricter post-condition for IndVarSimplify.

Fixes PR25578.  Test case by Michael Zolotukhin.

Reviewers: hfinkel, atrick, mzolotukhin

Subscribers: llvm-commits

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

llvm-svn: 254977

Summary:
(Note: the problematic invocation of hoistIVInc that caused PR24804 came
from IndVarSimplify, not from SCEVExpander itself)

Fixes PR24804.  Test case by David Majnemer.

Reviewers: hfinkel, majnemer, atrick, mzolotukhin

Subscribers: llvm-commits

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

llvm-svn: 254976

Will be used in a upcoming patch.

llvm-svn: 254975

We were using unneccessarily large initial sizes for these SmallVectors.  This was wasting around 50kb of memory for the O3 pipeline, even after the uniquing changes.  We're still using around 20kb which is a bit much, but it's definitely better.  This is about a 6% improvement in total O3 memory usage.

Note: The raw data on structure size which were used to pick these thresholds can be found in the review thread.

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

llvm-svn: 254974

llvm-svn: 254968

llvm-svn: 254967

A manipulation (in this case, mkdir) can make slack between creating and touching %t.older/evenlen.

I would make this rewrote with python if this were still unstable.

llvm-svn: 254965

Based on patch by Pete Cooper.

llvm-svn: 254964

llvm-svn: 254963

llvm-svn: 254960

254950 ended up being not NFC.  The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI.  I'd missed this in my refactoring.  Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin.

This raises an interesting issue though.  Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all?  I see no reason for this, but decided to preserve existing behavior for the moment.  The root issue might be that we don't have a "writeonly" attribute.

Original commit message:
[EarlyCSE] Simplify and invert ParseMemoryInst [NFCI]

Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.

The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.

Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.

llvm-svn: 254957

This is supposed to force-link the Interpreter, by inserting a dead
call to LLVMLinkInInterpreter().
Since it is actually an empty function, there is no reason for the
call to be dead.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254956

It's causing test failures on AArch64.  Due to a bad build config on my part, I apparently wasn't running the tests I thought I was.

llvm-svn: 254954

llvm-svn: 254953

llvm-svn: 254952

Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.

The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.

Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.

llvm-svn: 254950

When considering foo->bar inlining, if there is an indirect call in foo which gets resolved to a direct call (say baz), then we try to inline baz into bar with a threshold T and subtract max(T - Cost(bar->baz), 0) from Cost(foo->bar). This patch uses max(Threshold(bar->baz) - Cost(bar->baz)) instead, where Thresheld(bar->baz) could be different from T due to bonuses or subtractions. Threshold(bar->baz) - Cost(bar->baz) better represents the desirability of inlining baz into bar.

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

llvm-svn: 254945