LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.

This patch makes build-llvm.py consult a directory full 
of .json files, each one of which matches a particular
branch using a regular expression.

This update to the patch introduces a FALLBACK file
whose contents take precedence if the current branch
could not be identified.  If the current branch could be
identified, FALLBACK is updated, allowing the user to
e.g. cut branches off of known branches and still have
the automatic checkout mechanism work.

It also documents all of this.

Differential revision: https://reviews.llvm.org/D30275

llvm-svn: 295922

Rather than attempting to compare whether the previous and current top of
context stack are "equal" (which fails for a number of reasons, such as the
context stack entries containing pointers to objects on the stack, or reaching
the same "top of stack" entry through two different paths), track the depth of
context stack at which we last emitted a note and invalidate it when we pop the
context stack to less than that depth.

This causes us to emit some missing "in instantiation of" notes and to stop
emitting redundant "in instantiation of" stacks matching the previous stack in
rare cases.

llvm-svn: 295921

Trivially define native_tan as a redirect to tan.

If there are any targets with a native implementation, we can deal with it later.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <arsenm2@gmail.com>
llvm-svn: 295920

using it for other kinds of context (where we currently produce context notes
in a highly ad-hoc manner).

llvm-svn: 295919

llvm-svn: 295918

llvm-svn: 295917

See https://llvm.org/bugs/show_bug.cgi?id=31439; this reflects LLVM's
behavior in practice, and should be compatible with C/C++ rules.

Differential Revision: https://reviews.llvm.org/D28026

llvm-svn: 295916

llvm-svn: 295915

llvm-svn: 295914

Previously, bitcode files in library paths were passed to the MSVC linker.
This patch strips them.

llvm-svn: 295913

This is the pattern that falls out of the instruction's
definition if offset == 0.

llvm-svn: 295912

IdentifierInfo is hashed based on the stored string.  FieldDecl versus other
Decl is now detected, as well as differently named fields.

Differential Revision: https://reviews.llvm.org/D21675

llvm-svn: 295911

llvm-svn: 295909

llvm-svn: 295908

- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block

<rdar://problem/30644888>

llvm-svn: 295907

llvm-svn: 295906

The manual is unclear on the details of this. It's not
clear to me if denormals are not allowed with clamp,
or if that is only omod. Not allowing denorms for
fp16 or fp64 isn't useful so I also question if that
is really a restriction. Same with whether this is valid
without IEEE mode enabled.

llvm-svn: 295905

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

llvm-svn: 295904

rdar://30603803

llvm-svn: 295903

This test now passes on darwin.

llvm-svn: 295902

llvm-svn: 295901

We need to investigate this, but for now it just causes too much
headache when trying to run these tests.

llvm-svn: 295900

llvm-svn: 295899

[InstCombine] don't try SimplifyDemandedInstructionBits from add/sub because it's slow and unlikely to succeed

Notably, no regression tests change when we remove these calls, and these are expensive calls.

The motivation comes from the general acknowledgement that the compiler is getting slower:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109188.html
http://lists.llvm.org/pipermail/llvm-dev/2016-December/108279.html

And specifically the test case attached to PR32037:
https://bugs.llvm.org//show_bug.cgi?id=32037

Profiling the middle-end (opt) part of the compile:
$ ./opt -O2 row_common.bc -o /dev/null

...visitAdd and visitSub are near the top of the instcombine list, and the calls to SimplifyDemandedInstructionBits()
are high within each of those. Those calls account for 1%+ of the opt time in either debug or release profiles. And 
that's the rough win I see from this patch when testing opt built release from r295864 on an iMac with Haswell 4GHz
(model 4790K).

It seems unlikely that we'd be able to eliminate add/sub or change their operands given that add/sub normally affect
all bits, and the PR32037 example shows no IR difference after this change using -O2.

Also worth noting - the code comment in visitAdd:
// This handles stuff like (X & 254)+1 -> (X&254)|1
...isn't true. That transform is handled later with a call to haveNoCommonBitsSet().

Differential Revision: https://reviews.llvm.org/D30270

llvm-svn: 295898

LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.

This patch makes build-llvm.py consult a directory full 
of .json files, each one of which matches a particular
branch using a regular expression.

Differential revision: https://reviews.llvm.org/D30275

llvm-svn: 295897

Added virtual destructor in a class containing virtual functions.

Differential Revision: https://reviews.llvm.org/D30271

llvm-svn: 295896

Fixes the build.

llvm-svn: 295895

This fixes a few assertion failures. Please see the added test case.

llvm-svn: 295894

llvm-svn: 295893

llvm-svn: 295892

This should avoid reporting any stack needs to be allocated in the
case where no stack is truly used. An unused stack slot is still
left around in other cases where there are real stack objects
but no spilling occurs.

llvm-svn: 295891

Add support for static_cast in classes.  Add pointer-independent profiling for
Stmt's, sharing most of the logic with Stmt::Profile.  This is the first of the
deep sub-Decl diffing for error messages.

Differential Revision: https://reviews.llvm.org/D21675

llvm-svn: 295890

Summary:
Depends on D29606 and D29682

Makes us pass GVN's edge.ll (we also will pass a few other testcases
they just need cleaning up).

Thoughts on the Predicate* hiearchy of classes especially welcome :)
(it's not clear to me how best to organize it, and currently, the getBlock* seems ... uglier than maybe wasting a field somewhere or something).

Reviewers: davide

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29747

llvm-svn: 295889

llvm-svn: 295888

Add updater to passes that now need it.
Move around code in MemorySSA to expose needed functions.

Summary: Mostly cleanup

Reviewers: george.burgess.iv

Subscribers: llvm-commits, Prazek

Differential Revision: https://reviews.llvm.org/D30221

llvm-svn: 295887

This is necessary in order for the evaluation of an _Atomic initializer for
those types to have an associated object, which an initializer for class or
array type needs.

llvm-svn: 295886

llvm-svn: 295885

After rL294814, LSR formula can have multiple SCEVAddRecExprs inside of its BaseRegs.
Previous canonicalization will swap the first SCEVAddRecExpr in BaseRegs with ScaledReg.
But now we want to swap the SCEVAddRecExpr Reg related with current loop with ScaledReg.
Otherwise, we may generate code like this: RegA + lsr.iv + RegB, where loop invariant
parts RegA and RegB are not grouped together and cannot be promoted outside of loop.
With this patch, it will ensure lsr.iv to be generated later in the expr:
RegA + RegB + lsr.iv, so that RegA + RegB can be promoted outside of loop.

Differential Revision: https://reviews.llvm.org/D26781

llvm-svn: 295884

llvm-svn: 295883

llvm-svn: 295882