| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 77266
|
| |
|
|
| |
llvm-svn: 77152
|
| |
|
|
|
|
|
|
|
|
| |
- Some clients which used DOUT have moved to DEBUG. We are deprecating the
"magic" DOUT behavior which avoided calling printing functions when the
statement was disabled. In addition to being unnecessary magic, it had the
downside of leaving code in -Asserts builds, and of hiding potentially
unnecessary computations.
llvm-svn: 77019
|
| |
|
|
|
|
| |
thanks to contexts-on-types. More to come.
llvm-svn: 77011
|
| |
|
|
|
|
| |
instead of getAnalysis<TargetData>().
llvm-svn: 76982
|
| |
|
|
| |
llvm-svn: 76962
|
| |
|
|
| |
llvm-svn: 76782
|
| |
|
|
| |
llvm-svn: 76702
|
| |
|
|
| |
llvm-svn: 76598
|
| |
|
|
| |
llvm-svn: 76595
|
| |
|
|
|
|
| |
doesn't cause ".no_dead_strip" to be emitted on darwin.
llvm-svn: 76399
|
| |
|
|
|
|
|
|
|
| |
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
llvm-svn: 76385
|
| |
|
|
| |
llvm-svn: 76284
|
| |
|
|
|
|
|
|
| |
number of issues in
our current context-passing stuff, which is also fixed here
llvm-svn: 76089
|
| |
|
|
|
|
| |
AllocaInst and MallocInst.
llvm-svn: 75863
|
| |
|
|
| |
llvm-svn: 75703
|
| |
|
|
|
|
|
|
|
| |
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
llvm-svn: 75640
|
| |
|
|
| |
llvm-svn: 75497
|
| |
|
|
|
|
|
|
|
| |
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
llvm-svn: 75379
|
| |
|
|
|
|
| |
the [I|F]CmpInst constructors. Who knew!?
llvm-svn: 75200
|
| |
|
|
|
|
| |
module is required.
llvm-svn: 75025
|
| |
|
|
| |
llvm-svn: 74985
|
| |
|
|
| |
llvm-svn: 74878
|
| |
|
|
|
|
| |
through the ValueTracking API.
llvm-svn: 74873
|
| |
|
|
|
|
| |
files.
llvm-svn: 74844
|
| |
|
|
| |
llvm-svn: 74811
|
| |
|
|
| |
llvm-svn: 74773
|
| |
|
|
|
|
|
|
| |
arguments/elements
to not have to create a temporary vector (in the API at least). Patch by Jay Foad!
llvm-svn: 74584
|
| |
|
|
|
|
| |
and llvm.dbg.global_variables.
llvm-svn: 74251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
>>
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken. I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>
The problem is replaceAllUsesWith asserts for type mismatch here. Try attached .bc with llvm-ld.
assert(New->getType() == getType() &&
"replaceAllUses of value with new value of different type!");
Since stack is always on address space zero, I don't think that type of GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces while comparing types. (do we have a way to do that ?).
But then such an optimization may fail the entire idea of user wanting to place a variable into different memory space. The original idea of user might be to save on the stack space (data memory) and hence he asked the variable to be placed into different memory space (program memory). So the best bet here is to deny this optimization by checking
GV->getType()->getAddressSpace() == 0.
llvm-svn: 73605
|
| |
|
|
| |
llvm-svn: 73412
|
| |
|
|
| |
llvm-svn: 73362
|
| |
|
|
| |
llvm-svn: 73342
|
| |
|
|
|
|
|
|
|
|
| |
is that, for functions whose bodies are entirely guarded by an if-statement, it
can be profitable to pull the test out of the callee and into the caller.
This code has had some cursory testing, but still has a number of known issues
on the LLVM test suite.
llvm-svn: 73338
|
| |
|
|
|
|
| |
pointer. This fixes kimwitu++. Pointed out by Frits van Bommel on review!
llvm-svn: 73299
|
| |
|
|
|
|
|
|
|
|
|
| |
the relationship with MergeFunctions.cpp's isEquivalentOperation,
and make a trivial code reordering so that the two functions are
easier to compare.
Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's
isEquivalentOperation's comment, and fix a nearby 80-column violation.
llvm-svn: 73241
|
| |
|
|
| |
llvm-svn: 73235
|
| |
|
|
| |
llvm-svn: 73231
|
| |
|
|
|
|
| |
thunks.
llvm-svn: 73230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
points to while analyzing all other fields.
Use FoldingSetNodeID to produce a good hash. This dramatically decreases run
times.
Emit thunks. This means that it can look at all functions regardless of what
the linkage is or if the address is taken, but unfortunately some small
functions can be even shorter than the thunk because our backend doesn't yet
realize it can just turn these into jumps. This means that this pass will
pessimize code on average.
llvm-svn: 73222
|
| |
|
|
| |
llvm-svn: 73164
|
| |
|
|
|
|
|
| |
identical function ConstantIsDead() to SafeToDestroyConstant(), to
emphasise the connection with Constant::destroyConstant().
llvm-svn: 73149
|
| |
|
|
|
|
| |
Instructions.
llvm-svn: 73002
|
| |
|
|
|
|
| |
can happen when PHI uses are recursively dependent on each other.
llvm-svn: 72710
|
| |
|
|
|
|
|
|
|
| |
and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.
llvm-svn: 72328
|
| |
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
| |
|
|
|
|
|
|
| |
the readnone. Since MallocInst is scheduled for deletion
it doesn't seem worth doing anything more subtle, such as
having mayWriteToMemory return true for MallocInst.
llvm-svn: 71077
|
| |
|
|
|
|
| |
them to bool.
llvm-svn: 70653
|
| |
|
|
|
|
| |
a default value, and will hopefully be going away soon.
llvm-svn: 70642
|
| |
|
|
| |
llvm-svn: 70630
|