- Jul 02, 2010
-
-
Gabor Greif authored
llvm-svn: 107500
-
Gabor Greif authored
llvm-svn: 107498
-
Dan Gohman authored
have any effect, and second, deleting stores can potentially invalidate an AliasAnalysis, and there's currently no notification for this. llvm-svn: 107496
-
Dan Gohman authored
the noalias argument on function attributes be usable to model the C99 restrict keyword on arguments, and to allow AliasAnalysis to consider a noalias-attributed argument to be an "identified object". To support this, refactor a new "based on" concept out of the current pointer aliasing "associated" concept. This "based on" concept is very similar to (though it is not identical with) the "based on" concept in C99. Also, reword the definition of NoAlias to more closely describe the concept that the optimizer uses. llvm-svn: 107495
-
Jakob Stoklund Olesen authored
This allows us to recognize the common case where all uses could be rematerialized, and no stack slot allocation is necessary. If some values could be fully rematerialized, remove them from the live range before allocating a stack slot for the rest. llvm-svn: 107492
-
Jim Grosbach authored
llvm-svn: 107490
-
Jim Grosbach authored
llvm-svn: 107489
-
Bob Wilson authored
that it checks the immediate values, not just the instructions opcodes. Radar 8110263. llvm-svn: 107487
-
Gabor Greif authored
llvm-svn: 107482
-
Gabor Greif authored
llvm-svn: 107481
-
Gabor Greif authored
second round of low-level interface squeeze-out: making all of CallInst's low-level operand accessors private If you get compile errors I strongly urge you to update your code. I tried to write the necessary clues into the header where the compiler may point to, but no guarantees. It works for my GCC. You have several options to update your code: - you can use the v2.8 ArgOperand accessors - you can go via a temporary CallSite - you can upcast to, say, User and call its low-level accessors if your code is definitely operand-order agnostic. If you run into serious problems, please comment in below thread (and back out this revision only if absolutely necessary): <http://groups.google.com/group/llvm-dev/browse_thread/thread/64650cf343b28271> llvm-svn: 107480
-
Dan Gohman authored
llvm-svn: 107458
-
Dan Gohman authored
llvm-svn: 107454
-
Dan Gohman authored
llvm-svn: 107451
-
Bruno Cardoso Lopes authored
llvm-svn: 107448
-
Dale Johannesen authored
llvm-svn: 107446
-
Bill Wendling authored
will still be stripped by the linker when it generates the final image. llvm-svn: 107440
-
Bruno Cardoso Lopes authored
llvm-svn: 107438
-
Bob Wilson authored
getFunctionAlignment and the corresponding use of that value in the ARM asm printer, but now we're using the standard asm printer. The result of this was that function alignments were dropped completely for Thumb functions. Radar 8143571. llvm-svn: 107435
-
- Jul 01, 2010
-
-
Bill Wendling authored
Objective-C metadata types which should be marked as "weak", but which the linker will remove upon final linkage. However, this linkage isn't specific to Objective-C. For example, the "objc_msgSend_fixup_alloc" symbol is defined like this: .globl l_objc_msgSend_fixup_alloc .weak_definition l_objc_msgSend_fixup_alloc .section __DATA, __objc_msgrefs, coalesced .align 3 l_objc_msgSend_fixup_alloc: .quad _objc_msgSend_fixup .quad L_OBJC_METH_VAR_NAME_1 This is different from the "linker_private" linkage type, because it can't have the metadata defined with ".weak_definition". Currently only supported on Darwin platforms. llvm-svn: 107433
-
Gabor Greif authored
to update their code to high-level interfaces If you get compile errors in your project please update your code according to the comments. This is a re-commit of r107396 which causes compile errors for the indicated usage patterns instead of link errors (which are less easy to fix because of missing source location). If you get compile errors please perform following functionally equivalent transformations: - getOperand(0) ---> getCalledValue() - setOperand(0, V) ---> setCalledFunction(V) This will make your code more future-proof and avoid potentially hard-to-debug bugs. please refer to this thread on llvm-dev: <http://groups.google.com/group/llvm-dev/browse_thread/thread/64650cf343b28271> llvm-svn: 107432
-
Devang Patel authored
This is a regression caused by r106792 and caught by gdb testsuite. llvm-svn: 107430
-
Daniel Dunbar authored
llvm-svn: 107428
-
Daniel Dunbar authored
llvm-svn: 107426
-
Daniel Dunbar authored
llvm-svn: 107425
-
Daniel Dunbar authored
llvm-svn: 107424
-
Dan Gohman authored
make it more aggressive in cases where both pointers are known to live in the same function. llvm-svn: 107420
-
Daniel Dunbar authored
Spencer! llvm-svn: 107418
-
Devang Patel authored
llvm-svn: 107417
-
Devang Patel authored
such a way that debug info for symbols preserved even if symbols are optimized away by the optimizer. Add new special pass to remove debug info for such symbols. llvm-svn: 107416
-
Devang Patel authored
llvm-svn: 107412
-
Bruno Cardoso Lopes authored
Add AVX SSE3 packed horizontal and & sub instructions llvm-svn: 107405
-
Bruno Cardoso Lopes authored
llvm-svn: 107404
-
Gabor Greif authored
llvm-svn: 107399
-
Gabor Greif authored
to update their code to high-level interfaces If you get compile errors in your project please update your code according to the comments. llvm-svn: 107396
-
Dan Gohman authored
llvm-svn: 107393
-
Gabor Greif authored
reformulate CallSiteBase::getCallee to adapt to CallInst::ArgOffset, and make it work even if CallInst::op_* are private llvm-svn: 107392
-
Gabor Greif authored
reformulate CallSite::getCallee to adapt to CallInst::ArgOffset, and make it work even if CallInst::op_* are private llvm-svn: 107390
-
Dan Gohman authored
doing the work manually. llvm-svn: 107384
-
Dan Gohman authored
from a Value to a Type, because it doesn't actually care about the Value. llvm-svn: 107383
-