| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
builds to "Release". The default build is unchanged (optimization on,
assertions on), however it is now called Release+Asserts. The intent
is that future LLVM releases released via llvm.org will be Release builds
in the new sense, i.e. will have assertions disabled (currently they have
assertions enabled, for a more than 20% slowdown). This will bring them
in line with MacOS releases, which ship with assertions disabled. It also
means that "Release" now means the same things in make and cmake builds:
cmake already disables assertions for "Release" builds AFAICS.
llvm-svn: 107758
|
| |
|
|
| |
llvm-svn: 107637
|
| |
|
|
| |
llvm-svn: 107516
|
| |
|
|
|
|
|
| |
have any effect, and second, deleting stores can potentially invalidate
an AliasAnalysis, and there's currently no notification for this.
llvm-svn: 107496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 107412
|
| |
|
|
| |
llvm-svn: 107335
|
| |
|
|
| |
llvm-svn: 107323
|
| |
|
|
| |
llvm-svn: 107278
|
| |
|
|
| |
llvm-svn: 107277
|
| |
|
|
| |
llvm-svn: 107275
|
| |
|
|
| |
llvm-svn: 107273
|
| |
|
|
| |
llvm-svn: 107272
|
| |
|
|
| |
llvm-svn: 107271
|
| |
|
|
| |
llvm-svn: 107270
|
| |
|
|
| |
llvm-svn: 107269
|
| |
|
|
| |
llvm-svn: 107215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. 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".
llvm-svn: 107205
|
| |
|
|
|
|
|
|
| |
is stripped off. Currently set unconditionally, since the API
does not provide a way of working out if anything was actually
stripped off.
llvm-svn: 107142
|
| |
|
|
| |
llvm-svn: 107017
|
| |
|
|
| |
llvm-svn: 107016
|
| |
|
|
| |
llvm-svn: 107015
|
| |
|
|
| |
llvm-svn: 107004
|
| |
|
|
| |
llvm-svn: 107003
|
| |
|
|
| |
llvm-svn: 107002
|
| |
|
|
| |
llvm-svn: 107000
|
| |
|
|
|
|
|
|
| |
large integers, the first inserted value would always create
an 'or X, 0'. Even though this is trivially zapped by
instcombine, don't bother creating this pointless instruction.
llvm-svn: 106979
|
| |
|
|
|
|
|
|
| |
the returned value after the tail call if it differs from other return
values. The optimal thing to do would be to introduce a phi node for
the return value, but for the moment just fix the miscompile.
llvm-svn: 106947
|
| |
|
|
|
|
|
|
| |
SCEVUnknown values which are loop-variant, as LSR can't do anything
interesting with these values in any case. This fixes very slow compile
times on loops which have large numbers of such values.
llvm-svn: 106897
|
| |
|
|
|
|
|
|
|
| |
for an "i" constraint should get lowered; PR 6309. While
this argument was passed around a lot, this is the only
place it was used, so it goes away from a lot of other
places.
llvm-svn: 106893
|
| |
|
|
| |
llvm-svn: 106825
|
| |
|
|
| |
llvm-svn: 106824
|
| |
|
|
|
|
| |
able to use isFreeCall whithout a cast or new overload
llvm-svn: 106823
|
| |
|
|
| |
llvm-svn: 106768
|
| |
|
|
| |
llvm-svn: 106764
|
| |
|
|
|
|
|
| |
enough special case, and it theoretically allows more folding because
it works even when x is unanalyzable.
llvm-svn: 106763
|
| |
|
|
| |
llvm-svn: 106759
|
| |
|
|
| |
llvm-svn: 106752
|
| |
|
|
| |
llvm-svn: 106750
|
| |
|
|
|
|
| |
perform some cosmetics
llvm-svn: 106747
|
| |
|
|
| |
llvm-svn: 106745
|
| |
|
|
| |
llvm-svn: 106744
|
| |
|
|
| |
llvm-svn: 106743
|
| |
|
|
| |
llvm-svn: 106740
|
| |
|
|
| |
llvm-svn: 106737
|
| |
|
|
|
|
| |
smoothly
llvm-svn: 106736
|
| |
|
|
| |
llvm-svn: 106734
|
| |
|
|
| |
llvm-svn: 106731
|
| |
|
|
| |
llvm-svn: 106730
|