phi node itself if it occurs in an unreachable basic block. Protect
against this. Hopefully this will fix some more buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119493 91177308-0d34-0410-b5e6-96231b3b80d8
cookie argument to the SourceMgr diagnostic stuff. This cleanly separates
LLVMContext's inlineasm handler from the sourcemgr error handling
definition, increasing type safety and cleaning things up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119486 91177308-0d34-0410-b5e6-96231b3b80d8
class, uses DominatorTree which is an analysis. This change moves all of
the tricky hasConstantValue logic to SimplifyInstruction, and replaces it
with a very simple literal implementation. I already taught users of
hasConstantValue that need tricky stuff to use SimplifyInstruction instead.
I didn't update InlineFunction because the IR looks like it might be in a
funky state at the point it calls hasConstantValue, which makes calling
SimplifyInstruction dangerous since it can in theory do a lot of tricky
reasoning. This may be a pessimization, for example in the case where
all phi node operands are either undef or a fixed constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119459 91177308-0d34-0410-b5e6-96231b3b80d8
testing for dereferenceable pointers into a helper function,
isDereferenceablePointer. Teach it how to reason about GEPs
with simple non-zero indices.
Also eliminate ArgumentPromtion's IsAlwaysValidPointer,
which didn't check for weak externals or out of range gep
indices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118840 91177308-0d34-0410-b5e6-96231b3b80d8
PR 8522 / 8616046. Test reduction, analysis and patch by Tim Deegan!
(However, review by someone who understands the classes here better
is welcome. John Krum will return!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118030 91177308-0d34-0410-b5e6-96231b3b80d8
instruction at the beginning of each function that has the attribute, allowing
the function to be easily hooked and/or patched.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117264 91177308-0d34-0410-b5e6-96231b3b80d8
A RegionPass is executed like a LoopPass but on the regions detected by the
RegionInfo pass instead of the loops detected by the LoopInfo pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116905 91177308-0d34-0410-b5e6-96231b3b80d8
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116820 91177308-0d34-0410-b5e6-96231b3b80d8
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116334 91177308-0d34-0410-b5e6-96231b3b80d8
initialization functions that initialize the set of passes implemented in
that library. Add C bindings for these functions as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115927 91177308-0d34-0410-b5e6-96231b3b80d8
expand to an initializeMyPass() function (in additional to the extant static ctors). Eventually, these will be called
from a big InitializeAllPasses() function, and the PassInfo's they create (which would be leaked if this code were used
at the moment) will be handed off to a PassRegistry for ownership.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115703 91177308-0d34-0410-b5e6-96231b3b80d8
it in with the SSSE3 instructions.
Steward! Could you place this chair by the aft sun deck? I'm trying to get away
from the Astors. They are such boors!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115552 91177308-0d34-0410-b5e6-96231b3b80d8
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics.
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces. Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
delete the MDNode that changed, rather than the other MDNode.
This is less work, because it doesn't require the changed node
to be re-inserted into the uniquing map and it doesn't require
the is-function-local flag to be recomputed. Also, it avoids
trouble when the existing node is part of a complicated
data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114996 91177308-0d34-0410-b5e6-96231b3b80d8
be possible to implement this very carefully to allow a lock-free implementation while still
avoiding illegal interleavings, but I haven't been able to figure one out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114046 91177308-0d34-0410-b5e6-96231b3b80d8
that all the setup of this class currently happens at static initialization time, this misses the fact
that some later events can cause mutation of the PassRegistrationListeners list, and thus cause race issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114036 91177308-0d34-0410-b5e6-96231b3b80d8
isn't a good level of abstraction for memdep. Instead, generalize
AliasAnalysis::alias and related interfaces with a new Location
class for describing a memory location. For now, this is the same
Pointer and Size as before, plus an additional field for a TBAA tag.
Also, introduce a fixed MD_tbaa metadata tag kind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113858 91177308-0d34-0410-b5e6-96231b3b80d8
