The MemCpyOpt pass is capable of optimizing:
      callee(&S); copy N bytes from S to D.
    into:
      callee(&D);
subject to some legality constraints. 

  Assertion is triggered when the compiler tries to evalute "sizeof(typeof(D))",
while D is an opaque-typed, 'sret' formal argument of function being compiled.
i.e. the signature of the func being compiled is something like this:
  T caller(...,%opaque* noalias nocapture sret %D, ...)

  The fix is that when come across such situation, instead of calling some
utility functions to get the size of D's type (which will crash), we simply
assume D has at least N bytes as implified by the copy-instruction.

rdar://14073661 

llvm-svn: 183584

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

r165941: Resubmit the changes to llvm core to update the functions to
         support different pointer sizes on a per address space basis.

Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.

However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.

In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.

In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.

This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.

llvm-svn: 167222

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

llvm-svn: 165941

llvm-svn: 165747

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

llvm-svn: 165402

have an alloca or a parameter, since then the alloca test should make sense
to readers, while before it probably appears too specific.  No functionality
change.

llvm-svn: 165306

cpyDest can be mutated in some cases, which would then cause a crash later if
indeed the memory was underaligned.  This brought down several buildbots, so
I guess the underaligned case is much more common than I thought!

llvm-svn: 165228

was less aligned than the old.  In the testcase this results in an overaligned
memset: the memset alignment was correct for the original memory but is too much
for the new memory.  Fix this by either increasing the alignment of the new
memory or bailing out if that isn't possible.  Should fix the gcc-4.7 self-host
buildbot failure.

llvm-svn: 165220

This is common when storing to global variables.

llvm-svn: 163809

llvm-svn: 160668

This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.

I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.

I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.

Thanks to Bill and Eric for giving the green light for this bit of cleanup.

llvm-svn: 159421

so that it can be reused in MemCpyOptimizer.  This analysis is needed to remove
an unnecessary memcpy when returning a struct into a local variable.
rdar://11341081
PR12686

llvm-svn: 156776

- Use unsigned literals when the desired result is unsigned. This mostly allows unsigned/signed mismatch warnings to be less noisy even if they aren't on by default.
- Remove misplaced llvm_unreachable.
- Add static to a declaration of a function on MSVC x86 only.
- Change some instances of calling a static function through a variable to simply calling that function while removing the unused variable.

llvm-svn: 150364

llvm-svn: 145866

where this would be bad as the backend shouldn't have a problem inlining small
memcpys.
rdar://10510150

llvm-svn: 145865

Suggested in code review by Eli.

That code in InstCombine looks kinda suspicious.

llvm-svn: 145013

on the memcpy call will pull up other unrelated stuff. Fixes PR11142.

llvm-svn: 142150

llvm-svn: 141750

llvm-svn: 137888

llvm-svn: 135375

llvm-svn: 135154

StructType::get() and TargetData::getIntPtrType().

llvm-svn: 134982

an assert on Darwin llvm-gcc builds.

Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, li\
ne 2067.
etc.

http://smooshlab.apple.com:8013/builders/llvm-gcc-i386-darwin9-RA/builds/2354

--- Reverse-merging r134893 into '.':
U    include/llvm/Target/TargetData.h
U    include/llvm/DerivedTypes.h
U    tools/bugpoint/ExtractFunction.cpp
U    unittests/Support/TypeBuilderTest.cpp
U    lib/Target/ARM/ARMGlobalMerge.cpp
U    lib/Target/TargetData.cpp
U    lib/VMCore/Constants.cpp
U    lib/VMCore/Type.cpp
U    lib/VMCore/Core.cpp
U    lib/Transforms/Utils/CodeExtractor.cpp
U    lib/Transforms/Instrumentation/ProfilingUtils.cpp
U    lib/Transforms/IPO/DeadArgumentElimination.cpp
U    lib/CodeGen/SjLjEHPrepare.cpp
--- Reverse-merging r134888 into '.':
G    include/llvm/DerivedTypes.h
U    include/llvm/Support/TypeBuilder.h
U    include/llvm/Intrinsics.h
U    unittests/Analysis/ScalarEvolutionTest.cpp
U    unittests/ExecutionEngine/JIT/JITTest.cpp
U    unittests/ExecutionEngine/JIT/JITMemoryManagerTest.cpp
U    unittests/VMCore/PassManagerTest.cpp
G    unittests/Support/TypeBuilderTest.cpp
U    lib/Target/MBlaze/MBlazeIntrinsicInfo.cpp
U    lib/Target/Blackfin/BlackfinIntrinsicInfo.cpp
U    lib/VMCore/IRBuilder.cpp
G    lib/VMCore/Type.cpp
U    lib/VMCore/Function.cpp
G    lib/VMCore/Core.cpp
U    lib/VMCore/Module.cpp
U    lib/AsmParser/LLParser.cpp
U    lib/Transforms/Utils/CloneFunction.cpp
G    lib/Transforms/Utils/CodeExtractor.cpp
U    lib/Transforms/Utils/InlineFunction.cpp
U    lib/Transforms/Instrumentation/GCOVProfiling.cpp
U    lib/Transforms/Scalar/ObjCARC.cpp
U    lib/Transforms/Scalar/SimplifyLibCalls.cpp
U    lib/Transforms/Scalar/MemCpyOptimizer.cpp
G    lib/Transforms/IPO/DeadArgumentElimination.cpp
U    lib/Transforms/IPO/ArgumentPromotion.cpp
U    lib/Transforms/InstCombine/InstCombineCompares.cpp
U    lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
U    lib/Transforms/InstCombine/InstCombineCalls.cpp
U    lib/CodeGen/DwarfEHPrepare.cpp
U    lib/CodeGen/IntrinsicLowering.cpp
U    lib/Bitcode/Reader/BitcodeReader.cpp

llvm-svn: 134949

llvm-svn: 134888

Stop using memdep for a check that didn't really make sense with memdep. In terms of specific issues, using memdep here checks irrelevant instructions and won't work properly once we start returning "unknown" more aggressively from memdep.

llvm-svn: 133035

Add "unknown" results for memdep, which mean "I don't know whether a dependence for the given instruction exists in the given block".  This cleans up all the existing hacks in memdep which represent this concept by returning clobber with various unrelated instructions.

llvm-svn: 133031

PR10067: Add missing safety check to call return transformation in MemCpyOpt::processStore.  If something accesses the dest of the "copy" between the call and the copy, the performCallSlotOptzn transformation is not valid.

llvm-svn: 132485

aligned.

Teach memcpyopt to not give up all hope when confonted with an underaligned
memcpy feeding an overaligned byval.  If the *source* of the memcpy can be
determined to be adequeately aligned, or if it can be forced to be, we can
eliminate the memcpy.

This addresses PR9794.  We now compile the example into:

define i32 @f(%struct.p* nocapture byval align 8 %q) nounwind ssp {
entry:
  %call = call i32 @g(%struct.p* byval align 8 %q) nounwind
  ret i32 %call
}

in both x86-64 and x86-32 mode.  We still don't get a tailcall though,
because tailcalls apparently can't handle byval.

llvm-svn: 131884

llvm-svn: 130876

problem reported on cfe-dev.

llvm-svn: 130661

Luis Felipe Strano Moraes!

llvm-svn: 129558

llvm-svn: 125563

how they should be checked.

llvm-svn: 123999

llvm-svn: 123302

of the bootstrap miscompare issue.

llvm-svn: 123299

the source of the bootstrap problem.

llvm-svn: 123298

llvm-svn: 123149