llvm-svn: 200907

Ideally only those transform passes that run at -O0 remain enabled,
in reality we get as close as we reasonably can.
Passes are responsible for disabling themselves, it's not the job of
the pass manager to do it for them.

llvm-svn: 200892

Self-memcpy-elision and memcpy of constant byte to memset transforms don't care how many bytes you were trying to transfer. Sink that safety test after those transforms. Noticed by inspection.

llvm-svn: 200726

llvm-svn: 199836

can be used by both the new pass manager and the old.

This removes it from any of the virtual mess of the pass interfaces and
lets it derive cleanly from the DominatorTreeBase<> template. In turn,
tons of boilerplate interface can be nuked and it turns into a very
straightforward extension of the base DominatorTree interface.

The old analysis pass is now a simple wrapper. The names and style of
this split should match the split between CallGraph and
CallGraphWrapperPass. All of the users of DominatorTree have been
updated to match using many of the same tricks as with CallGraph. The
goal is that the common type remains the resulting DominatorTree rather
than the pass. This will make subsequent work toward the new pass
manager significantly easier.

Also in numerous places things became cleaner because I switched from
re-running the pass (!!! mid way through some other passes run!!!) to
directly recomputing the domtree.

llvm-svn: 199104

directory. These passes are already defined in the IR library, and it
doesn't make any sense to have the headers in Analysis.

Long term, I think there is going to be a much better way to divide
these matters. The dominators code should be fully separated into the
abstract graph algorithm and have that put in Support where it becomes
obvious that evn Clang's CFGBlock's can use it. Then the verifier can
manually construct dominance information from the Support-driven
interface while the Analysis library can provide a pass which both
caches, reconstructs, and supports a nice update API.

But those are very long term, and so I don't want to leave the really
confusing structure until that day arrives.

llvm-svn: 199082

If there are no legal integers, assume 1 byte.

This makes more sense than using the pointer size as
a guess for the maximum GPR width.

It is conceivable to want to use some 64-bit pointers
on a target where 64-bit integers aren't legal.

llvm-svn: 190817

Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.

llvm-svn: 185540

  r183584 tries to derive some info from the code *AFTER* a call and apply
these derived info to the code *BEFORE* the call, which is not always safe
as the call in question may never return, and in this case, the derived
info is invalid.
  
  Thank Duncan for pointing out this potential bug.

rdar://14073661 

llvm-svn: 183606

  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