|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| | address spaces when SRoA'ing memcpy's.
llvm-svn: 107846 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 |