GCC was emitting a signed vs unsigned comparison warning.

llvm-svn: 215620

Transform ((B | C) & A) | B --> B | (A & C)

Z3 Link: http://rise4fun.com/Z3/hP6p

Patch by Sonam Kumari!

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

llvm-svn: 215619

It doesn't really make sense to try and do stuff with #pragma init_seg
when targeting non-Microsoft platforms; notions like library vs user
initializers don't exist for other targets.

This fixes PR20639.

llvm-svn: 215618

avoids users of AllDiagnostics.h from needing to pregenerate *all* generated
headers. Hopefully this will make my modules buildbot happier...

llvm-svn: 215617

declaration has its definition instantiated in two sibling modules and they use
a partial specialization.

llvm-svn: 215616

As X86MCAsmInfoDarwin uses '##' as CommentString although a single '#' starts a
comment a workaround for this special case is added.

Fixes divisions in constant expressions for the AArch64 assembler and other
targets which use '//' as CommentString.

Patch by Janne Grunau!

llvm-svn: 215615

Currently when laying out bitfields that don't need any padding, we
represent them as a wide enough int to contain all of the bits. This
can be hard on the backend since we'll do things like represent stores
to a few bits as loading an i144, masking it with a large constant,
and storing it back.

This turns up in less pathological cases where we load and mask 64 bit
word on a 32 bit platform when we actually only need to access 32 bits.
This leads to bad code being generated in most of our 32 bit backends.

In practice, there are often natural breaks in bitfields, and it's a
fairly simple and effective heuristic to split these fields into legal
integer sized chunks when it will be equivalent (ie, it won't force us
to add any extra padding).

llvm-svn: 215614

Patch by Anthony Pesch. Thanks Anthony!

llvm-svn: 215613

definitions (because some other declaration declares a special member that
isn't present in the canonical definition), we need to search *all* of them; we
can't just stop when we find the requested name in any of the definitions,
because that can fail to find things (and in particular, it can fail to find
the member of the canonical declaration and return a bogus ODR failure).

llvm-svn: 215612

combining by replacing it with something else but not re-process the
node afterward to remove it.

In a truly remarkable stroke of bad luck, this would (in the test case
attached) end up getting some other node combined into it without ever
getting re-processed. By adding it back on to the worklist, in addition
to deleting the dead nodes more quickly we also ensure that if it
*stops* being dead for any reason it makes it back through the
legalizer. Without this, the test case will end up failing during
instruction selection due to an and node with a type we don't have an
instruction pattern for.

It took many million runs of the shuffle fuzz tester to find this.

llvm-svn: 215611

llvm-svn: 215610

This fixes a regression I caused back in r211766.

llvm-svn: 215609

Don't enable STDIN for cases where we are supplying lines to be run in the embedded python interpreter.

<rdar://problem/17949057>

llvm-svn: 215608

llvm-svn: 215607

llvm-svn: 215606

In general two-level namespace means each program records exactly which dylib
each undefined (imported) symbol comes from.  But, sometimes the implementor
wants to hide the implementation dylib.  For instance libSytem.dylib is the base
dylib all Darwin programs must link with.  A few years ago it was split up
into two dozen dylibs by all are hidden behind libSystem.dylib which re-exports
each sub-dylib.  All clients still think libSystem.dylib is the implementor.

To support this, the linker must load "indirect" dylibs and not just the
"direct" dylibs specified on the command line.  This is done in the
createImplicitFiles() method after all command line specified files are
loaded.  Since an indirect dylib may have already been loaded as a direct dylib
(or indirectly via a previous direct dylib), the MachOLinkingContext keeps
a list of all loaded dylibs.

With this change hello world can now be linked against the real OS or SDK.

llvm-svn: 215605

Found by code inspection.

llvm-svn: 215604

found in global pool as well. rdar://16808765

llvm-svn: 215603

Split up the CRuntimeFile into one part for output types that need an entry
point and another part for output types that use stubs.

Add file 'test/mach-o/Inputs/libSystem.yaml' for use by test cases that
use -dylib and therefore may now need the helper symbol in libSystem.dylib.

llvm-svn: 215602

Sorry about the noise.

llvm-svn: 215601

Certain functions such as objc_autoreleaseReturnValue have to be called as
tail-calls even at -O0. Since normal fast-isel doesn't emit calls as tail calls,
we have to fall back to SelectionDAG to select calls that are marked as tail.

<rdar://problem/17991614>

llvm-svn: 215600

Implement __pld, __pldx, __pli and __plix builtin intrinsics as specified in
ARM ACLE 2.0.

llvm-svn: 215599

Mach-o uses "two-level namespace" where each undefined symbols is associated
with a specific dylib. This means at runtime the loader (dyld) does need to
search all loaded dylibs for that symbol but rather just the one specified.

Now that llvm-nm -m prints out that info, properly set that info, and test
it in the hello world test cases.

llvm-svn: 215598

FastISel didn't take much advantage of the different addressing modes available
to it on AArch64. This commit allows the ComputeAddress method to recognize more
addressing modes that allows shifts and sign-/zero-extensions to be folded into
the memory operation itself.

For Example:
  lsl x1, x1, #3     --> ldr x0, [x0, x1, lsl #3]
  ldr x0, [x0, x1]

  sxtw x1, w1
  lsl x1, x1, #3     --> ldr x0, [x0, x1, sxtw #3]
  ldr x0, [x0, x1]

llvm-svn: 215597

Use the right mechanism to put the XPC services now that Xcode supports the workflow.

llvm-svn: 215596

In the large code model for X86 floating-point constants are placed in the
constant pool and materialized by loading from it. Since the constant pool
could be far away, a PC relative load might not work. Therefore we first
materialize the address of the constant pool with a movabsq and then load
from there the floating-point value.

Fixes <rdar://problem/17674628>.

llvm-svn: 215595

llvm-svn: 215594

This mostly affects the i64 value type, which always resulted in an 15byte
mobavsq instruction to materialize any constant. The custom code checks the
value of the immediate and tries to use a different and smaller mov
instruction when possible.

This fixes <rdar://problem/17420988>.

llvm-svn: 215593

llvm-svn: 215592

This change materializes now the value "0" from the zero register.
The zero register can be folded by several instruction, so no
materialization is need at all.

Fixes <rdar://problem/17924413>.

llvm-svn: 215591

FIXME: It seems this might be incompatible to dos path. Investigating.
llvm-svn: 215590

llvm-svn: 215589

This changes the order in which FastISel tries to materialize a constant.
Originally it would try to use a simple target-independent approach, which
can lead to the generation of inefficient code.

On X86 this would result in the use of movabsq to materialize any 64bit
integer constant - even for simple and small values such as 0 and 1. Also
some very funny floating-point materialization could be observed too.

On AArch64 it would materialize the constant 0 in a register even the
architecture has an actual "zero" register.

On ARM it would generate unnecessary mov instructions or not use mvn.

This change simply changes the order and always asks the target first if it
likes to materialize the constant. This doesn't fix all the issues
mentioned above, but it enables the targets to implement such
optimizations.

Related to <rdar://problem/17420988>.

llvm-svn: 215588

This is a cleaner solution to the problem described in r215431.
When instructions are combined a dangling DBG_VALUE is removed.
This resolves bug 20598.

llvm-svn: 215587

Split the constant materialization code into three separate helper functions for
Integer-, Floating-Point-, and GlobalValue-Constants.

llvm-svn: 215586

The tests in r215568 hard code a value as %0 in their checks. This
isn't correct in asserts builds.

llvm-svn: 215585

This change is also in preparation for a future change to make sure that
the constant materialization uses MOVT/MOVW when available and not a load
from the constant pool.

llvm-svn: 215584

getRegClassFor returns the incorrect register class when in Thumb2 mode.
This fix simply manually selects the register class as in the code just a few
lines above.

There is no test case for this code, because the code is currently
unreachable. This will be changed in a future commit and existing test
cases will exercise this code.

llvm-svn: 215583

Cleanup and prepare constant materialization code for future commits.

llvm-svn: 215582

// rdar://16808765

llvm-svn: 215581