llvm-svn: 164663

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164662

- Instead of embedding 'lock' into each mnemonic of atomic
  instructions except 'xchg', we teach X86 assembly printer to output 'lock'
  prefix similar to or consistent with code emitter.

llvm-svn: 164659

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164657

Fixed issue with Release build.

llvm-svn: 164654

The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.

This reverts r164633 / ba48ceb1a3802e20e781ef04ea2573ffae2ac414.

llvm-svn: 164651

llvm-svn: 164642

only a missed optimization opportunity if the store is over-aligned, but a
miscompile if the store's new type has a higher natural alignment than the
memcpy did. Fixes PR13920!

llvm-svn: 164641

llvm-svn: 164640

reason we were getting two of the same alloca is because of a memmove/memcpy
which had the same alloca in both the src and dest. Now we detect that case
directly. This has the same testcase as before, but fixes a clang test
CodeGenObjC/exceptions.m which runs clang -O2.

llvm-svn: 164636

Chandler, it's not obvious that it's okay that this alloca gets into the list
twice to begin with. Please review and see whether this is the fix you really
want, but I wanted to get a fix checked in quickly.

llvm-svn: 164634

llvm-svn: 164633

llvm-svn: 164631

llvm-svn: 164630

llvm-svn: 164629

Provide interface in TargetLowering to set or get the minimum number of basic
blocks whereby jump tables are generated for switch statements rather than an
if sequence.

    getMinimumJumpTableEntries() defaults to 4.
    setMinimumJumpTableEntries() allows target configuration.

    This patch changes the default for the Hexagon architecture to 5
    as it improves performance on some benchmarks.

llvm-svn: 164628

llvm-svn: 164627

doesn't transform the trivially unsafe case.

llvm-svn: 164617

- Turn on atomic6432.ll and add specific test case as well

llvm-svn: 164616

When a BL/BLX references a symbol in the same translation unit that is
out of range, use an external relocation. The linker will use this to
generate a branch island rather than a direct reference, allowing the
relocation to resolve correctly.

rdar://12359919

llvm-svn: 164615

llvm-svn: 164614

llvm-svn: 164611

to chains or cycles between PHIs and/or selects. Also add a couple of
really nice test cases reduced from Kostya's reports in PR13905 and
PR13906. Both are fixed by this patch.

llvm-svn: 164596

Previously it was only be able to detect problems if the pointer was a numerical
value (eg inttoptr i32 1 to i32*), but not if it was an alloca or globa.  The
reason was the use of ComputeMaskedBits: imagine you have "alloca i8, align 2",
and ask ComputeMaskedBits what it knows about the bits of the alloca pointer.
It can tell you that the bottom bit is known zero (due to align 2) but it can't
tell you that bit 1 is known one.  That's because the address could be an even
multiple of 2 rather than an odd multiple, eg it might be a multiple of 4.  Thus
trying to use KnownOne is ineffective in the case of an alloca as it will never
have any bits set.  Instead look explicitly for constant offsets from allocas
and globals.

llvm-svn: 164595

Fix an illegal tailcall opt where the callee returns a double via xmm while caller returns x86_fp80 via st0. rdar://12229511

llvm-svn: 164588

llvm-svn: 164587

David (I think), but I would appreciate folks verifying that this fixes
the big crasher.

I'm still working on a reduced test case, but because this was causing
problems I wanted to get the fix checked in quickly.

llvm-svn: 164585

it's not a dead store if that pointer is used. Whoops!

llvm-svn: 164583

Unit tests for IntegerDivision. Currently, just a basic sanity check to ensure that the code was generated properly. Future work would be finding some way to test the actual result that would be computed.

llvm-svn: 164582

rdar://9795790

llvm-svn: 164577

declaration to use the same form as in the rest of the file. No functionality
change.

llvm-svn: 164576

Even out-of-line jump tables can be in the code section, so mark them
as data-regions for those targets which support the directives.

rdar://12362871&12362974

llvm-svn: 164571

llvm-svn: 164570

Also remove an unused argument.

llvm-svn: 164567

I also moved the SDKROOT setting into the make flags, since clearing it from
the environment isn't good enough to override a setting on the make command
line.  That hasn't been a problem but it could be, and it's good to be
consistent with the way UNIVERSAL_SDK_PATH is handled.

llvm-svn: 164565

dead.

llvm-svn: 164561

No functionality change.

llvm-svn: 164560

store when handling byval arguments. Thus preventing reordering of the store
with load with post-RA scheduler.

llvm-svn: 164553

llvm-svn: 164548

llvm-svn: 164540