| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 168943
|
|
|
|
|
|
|
| |
start up and clean up module passes, now that ASAN and TSAN are fixed the
tests pass
llvm-svn: 168905
|
|
|
|
|
|
|
|
| |
"unsafe" mode.
Approved by: Eli and Michael.
llvm-svn: 168848
|
|
|
|
| |
llvm-svn: 168792
|
|
|
|
|
|
|
|
|
| |
Accordingly, update a testcase with a broken datalayout string.
Also, we never parse negative numbers, because '-' is used as a
separator. Therefore, use unsigned as result type.
llvm-svn: 168785
|
|
|
|
|
|
| |
The dependent libraries feature was never used and has bit-rotted. Remove it.
llvm-svn: 168694
|
|
|
|
|
|
|
|
| |
doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model".
It appears to have broken at least one buildbot.
llvm-svn: 168654
|
|
|
|
|
|
| |
Added in the ability to read LLVM IR text that contains fast-math flags as a sequence of capital letters separated by spaces in any order. Added in the printing of the fast-math flags in a canonical order, and don't print the other flags when 'fast' is specified, as 'fast' implies all the others.
llvm-svn: 168645
|
|
|
|
|
|
| |
Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled.
llvm-svn: 168642
|
|
|
|
|
|
|
|
| |
doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model
Patch by Pedro Artigas, with feedback from by Chandler Carruth.
llvm-svn: 168635
|
|
|
|
|
|
| |
The bug can be triggered when we require LoopInfo analysis ahead of DominatorTree construction in a Module Pass. The cause is that the LoopInfo analysis itself also invokes DominatorTree construction, therefore, when PassManager schedules LoopInfo, it will add DominatorTree first. Then after that, when the PassManger turns to schedule DominatorTree invoked by the above ModulePass, it finds there is already a DominatorTree, so it delete the redundant one. However, somehow it still try to access that pass pointer after free as code pasted below, which results in segment fault.
llvm-svn: 168581
|
|
|
|
|
|
|
|
| |
trivial copy ctors.
No functionality change.
llvm-svn: 168561
|
|
|
|
|
|
| |
Update some test cases accordingly.
llvm-svn: 168516
|
|
|
|
|
|
|
|
|
| |
When code deletes the context, the AttributeImpls that the AttrListPtr points to
are now invalid. Therefore, instead of keeping a separate managed static for the
AttrListPtrs that's reference counted, move it into the LLVMContext and delete
it when deleting the AttributeImpls.
llvm-svn: 168354
|
|
|
|
| |
llvm-svn: 168344
|
|
|
|
| |
llvm-svn: 168338
|
|
|
|
| |
llvm-svn: 168304
|
|
|
|
|
|
|
|
| |
Instruction* corollary, which may be useful if a user
wishes to transform a ConstantExpr so that one of its operands is no longer constant.
llvm-svn: 168262
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that the operands of a Constant are not always themselves
Constant. For example, one of the operands of BlockAddress is
BasicBlock, which is not a Constant.
This should fix the dragonegg-x86_64-linux-gcc-4.6-test build which
broke in r168037.
llvm-svn: 168147
|
|
|
|
| |
llvm-svn: 168103
|
|
|
|
| |
llvm-svn: 168049
|
|
|
|
| |
llvm-svn: 168042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.
This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.
llvm-svn: 168037
|
|
|
|
|
|
|
|
| |
them to be re-initialized and reused on multiple Module's.
Patch by Pedro Artigas.
llvm-svn: 168008
|
|
|
|
|
|
|
|
|
| |
This seems like redundant leftovers from r142288 - exposing
TargetData::parseSpecifier to LLParser - which got reverted. Removes
redunant td != NULL checks in parseSpecifier, and simplifies the
interface to parseSpecifier and init.
llvm-svn: 167924
|
|
|
|
|
|
|
|
| |
temporarily as it is breaking the gdb bots.
This reverts commit r167806/e7ff4c14b157746b3e0228d2dce9f70712d1c126.
llvm-svn: 167886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in a vector of pointers, the pointer couldn't be any pointer type,
it had to be a pointer to an integer or floating point type. This is a hassle
for dragonegg because the GCC vectorizer happily produces vectors of pointers
where the pointer is a pointer to a struct or whatever. Vector getelementptr
was restricted to just one index, but now that vectors of pointers can have
any pointer type it is more natural to allow arbitrary vector getelementptrs.
There is however the issue of struct GEPs, where if each lane chose different
struct fields then from that point on each lane will be working down into
unrelated types. This seems like too much pain for too little gain, so when
you have a vector struct index all the elements are required to be the same.
llvm-svn: 167828
|
|
|
|
| |
llvm-svn: 167809
|
|
|
|
|
|
|
|
|
| |
If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>
llvm-svn: 167806
|
|
|
|
|
|
|
|
| |
getNumContainedPasses() used to compute the size of the vector on demand. It is
called repeated in loops (such as runOnFunction()) and it can be updated while
inside the loop.
llvm-svn: 167759
|
|
|
|
|
|
| |
C++ structs.
llvm-svn: 167334
|
|
|
|
|
|
| |
they are now all correct; hopefully the buildbots will agree!).
llvm-svn: 167289
|
|
|
|
|
|
|
|
|
| |
compute the address space in the one place it was used.
Also write the getPointerAddressSpace member in terms of the
getPointerOperandType member.
llvm-svn: 167226
|
|
|
|
|
|
|
|
|
|
| |
politely and document this feature.
This simple API extension then allows us to write all of the
Instructions' address space query methods much more simply. No
functionality change intended here.
llvm-svn: 167223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|
|
|
|
| |
llvm-svn: 167020
|
|
|
|
|
|
| |
with different sizes.
llvm-svn: 167018
|
|
|
|
|
|
|
| |
Simplify the implementation of the corresponding integer and float functions and
move them inline while there.
llvm-svn: 167014
|
|
|
|
|
|
| |
This fixes Clang :: CodeGen/complex-builtints.c on PowerPC.
llvm-svn: 167013
|
|
|
|
|
|
|
|
|
| |
wrapper returns a vector of integers when passed a vector of pointers) by having
getIntPtrType itself return a vector of integers in this case. Outside of this
wrapper, I didn't find anywhere in the codebase that was relying on the old
behaviour for vectors of pointers, so give this a whirl through the buildbots.
llvm-svn: 166939
|
|
|
|
|
|
| |
just call getPointerTypeSizeInBits. No functionality change.
llvm-svn: 166926
|
|
|
|
|
|
| |
other passes.
llvm-svn: 166794
|
|
|
|
| |
llvm-svn: 166772
|
|
|
|
| |
llvm-svn: 166607
|
|
|
|
|
|
| |
command. Bleh, sorry about this!
llvm-svn: 166596
|
|
|
|
| |
llvm-svn: 166591
|
|
|
|
|
|
|
|
|
| |
address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578
|
|
|
|
| |
llvm-svn: 166566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
called. Provide an (asserting) definition of Operator's private destructor.
Remove destructors from all classes derived from Operator. We don't need them
for safety, because their implicit definitions would be ill-formed (they'd call
Operator's private destructor), and we don't need them to avoid emitting
vtables, because we don't do anything with Operator subclasses which would
trigger vtable instantiation.
The Operator hierarchy is still a complete disaster with regard to undefined
behavior, but this at least allows LLVM to link when using Clang's
-fcatch-undefined-behavior with a new vptr-based type checking mechanism.
llvm-svn: 166530
|
|
|
|
| |
llvm-svn: 166467
|