summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Update llvm to trunk r256633.dim2015-12-30154-12172/+19960
|
* Upgrade our copies of clang and llvm to 3.7.1 release. This is adim2015-12-253-2/+8
| | | | | | | bugfix-only release, with no new features. Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
* Temporarily revert upstream llvm trunk r240144 (by Michael Zolotukhin):dim2015-10-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | [SLP] Vectorize for all-constant entries. This should fix libc++'s iostream initialization SIGBUSing on amd64, whenever the global cout symbol is not aligned to 16 bytes. Some further explanation: libc++'s iostream.cpp contains the definitions of std::cout, std::cerr and so on. These global objects are effectively declared with an alignment of 8 bytes. When an executable is linked against libc++.so, it can sometimes get a copy of the global object, which is then at the same alignment. However, with clang 3.7.0, the initialization of these global objects will incorrectly use SSE instructions (e.g. movdqa), whenever the optimization level is high enough, and SSE is enabled, such as on amd64. When any of these objects is not aligned to 16 bytes, this will result in a SIGBUS during iostream initialization. In contrast, clang 3.6.x and earlier took the 8 byte alignment into consideration, and avoided SSE for those particular operations. After bisecting of upstream changes, I found that the above revision caused the change of this behavior, so I am reverting it now as a workaround, while a discussion and test case is being prepared for upstream.
* Update llvm, clang and lldb to 3.7.0 release.dim2015-09-065-18/+65
|
* Update llvm/clang to r242221.dim2015-08-1229-671/+686
|
* Update llvm/clang to r241361.dim2015-07-05101-537/+783
|
* Merge ^/head r284737 through r285152.dim2015-07-042-2/+2
|\
| * Pull in r241142 from upstream llvm trunk (by David Majnemer):dim2015-07-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [SCCP] Turn loads of null into undef instead of zero initialized values Surprisingly, this is a correctness issue: the mmx type exists for calling convention purposes, LLVM doesn't have a zero representation for them. This partially fixes PR23999. Pull in r241143 from upstream llvm trunk (by David Majnemer): [LoopUnroll] Use undef for phis with no value live We would create a phi node with a zero initialized operand instead of undef in the case where no value was originally available. This was problematic for x86_mmx which has no null value. These fix a "Cannot create a null constant of that type!" error when compiling the graphics/sdl2_gfx port with MMX enabled. Reported by: amdmi3
* | Update llvm/clang to r240225.dim2015-06-23104-614/+1234
| |
* | Update Makefiles and other build glue for llvm/clang 3.7.0, as of trunkdim2015-06-1030-737/+1454
| | | | | | | | r239412.
* | Drop llvm/clang patches which are no longer necessary.dim2015-05-301-6/+1
| |
* | Merge llvm trunk r238337 from ^/vendor/llvm/dist, resolve conflicts, anddim2015-05-27137-11030/+23593
|/ | | | preserve our customizations, where necessary.
* Upgrade our copy of clang and llvm to 3.6.1 release.dim2015-05-253-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | This release contains the following cherry-picked revisions from upstream trunk: 226124 226151 226164 226165 226166 226407 226408 226409 226652 226905 226983 227084 227087 227089 227208 227209 227210 227211 227212 227213 227214 227269 227430 227482 227503 227519 227574 227822 227986 227987 227988 227989 227990 228037 228038 228039 228040 228188 228189 228190 228273 228372 228373 228374 228403 228765 228848 228918 229223 229225 229226 229227 229228 229230 229234 229235 229236 229238 229239 229413 229507 229680 229750 229751 229752 229911 230146 230147 230235 230253 230255 230469 230500 230564 230603 230657 230742 230748 230956 231219 231237 231245 231259 231280 231451 231563 231601 231658 231659 231662 231984 231986 232046 232085 232142 232176 232179 232189 232382 232386 232389 232425 232438 232443 232675 232786 232797 232943 232957 233075 233080 233351 233353 233409 233410 233508 233584 233819 233904 234629 234636 234891 234975 234977 235524 235641 235662 235931 236099 236306 236307 Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
* Merge ^/head r279023 through r279162.dim2015-02-221-0/+2
|\
| * Pull in r230058 from upstream llvm trunk (by Benjamin Kramer):dim2015-02-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LoopRotate: When reconstructing loop simplify form don't split edges from indirectbrs. Yet another chapter in the endless story. While this looks like we leave the loop in a non-canonical state this replicates the logic in LoopSimplify so it doesn't diverge from the canonical form in any way. http://llvm.org/PR21968 This fixes a "Cannot split critical edge from IndirectBrInst" assertion failure when building the devel/radare2 port. PR: 195480, 196987 MFC after: 3 days
* | Merge llvm 3.6.0rc4 from ^/vendor/llvm/dist, merge clang 3.6.0rc4 fromdim2015-02-193-27/+47
| | | | | | | | ^/vendor/clang/dist, resolve conflicts, and update patches.
* | Merge llvm 3.6.0rc3 from ^/vendor/llvm/dist, merge clang 3.6.0rc3 fromdim2015-02-149-43/+160
| | | | | | | | ^/vendor/clang/dist, resolve conflicts, and update patches README.
* | Merge llvm 3.6.0rc2 from ^/vendor/llvm/dist, merge clang 3.6.0rc2 fromdim2015-01-318-27/+54
| | | | | | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* | Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromdim2015-01-25114-7762/+14136
|/ | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Upgrade our copy of clang and llvm to 3.5.1 release. This is a bugfixdim2015-01-184-21/+45
| | | | | | | | | | | | | | only release, no new features have been added. Please note that this version requires C++11 support to build; see UPDATING for more information. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.5.1/docs/ReleaseNotes.html> <http://llvm.org/releases/3.5.1/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month X-MFC-With: 276479
* Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):dim2014-12-091-0/+9
| | | | | | | | | | | | | | | | | PR21302. Vectorize only bottom-tested loops. rdar://problem/18886083 This fixes a bug in the llvm vectorizer, which could sometimes cause vectorized loops to perform an additional iteration, leading to possible buffer overruns. Symptoms of this, which are usually segfaults, were first noticed when building gcc ports, here: https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-September/001211.html Note: because this is applied on top of llvm/clang 3.5.0, this fix is slightly different from the one just checked into head in r275633.
* Pull in r222856 from upstream llvm trunk (by David Majnemer):dim2014-11-271-28/+1
| | | | | | | | | | | Revert "Added inst combine transforms for single bit tests from Chris's note" This reverts commit r210006, it miscompiled libapr which is used in who knows how many projects. A test has been added to ensure that we don't regress again. This fixes a miscompilation in libapr, which caused problems in svnlite.
* Merge llvm 3.5.0 release from ^/vendor/llvm/dist, resolve conflicts, anddim2014-11-24137-12193/+19230
| | | | preserve our customizations, where necessary.
* Upgrade our copy of llvm/clang to 3.4.1 release. This release containsdim2014-05-125-17/+44
| | | | | | | | | | | | | | | mostly fixes, for the following upstream bugs: http://llvm.org/PR16365 http://llvm.org/PR17473 http://llvm.org/PR18000 http://llvm.org/PR18068 http://llvm.org/PR18102 http://llvm.org/PR18165 http://llvm.org/PR18260 http://llvm.org/PR18290 http://llvm.org/PR18316 http://llvm.org/PR18460 http://llvm.org/PR18473 http://llvm.org/PR18515 http://llvm.org/PR18526 http://llvm.org/PR18600 http://llvm.org/PR18762 http://llvm.org/PR18773 http://llvm.org/PR18860 http://llvm.org/PR18994 http://llvm.org/PR19007 http://llvm.org/PR19010 http://llvm.org/PR19033 http://llvm.org/PR19059 http://llvm.org/PR19144 http://llvm.org/PR19326 MFC after: 2 weeks
* Upgrade our copy of llvm/clang to 3.4 release. This version supportsdim2014-02-16109-9380/+17921
| | | | | | | | | | | | | | | | | all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y. The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month
* Pull in r189672 from upstream llvm trunk:dim2013-08-301-10/+15
| | | | | | | | | | | | | | InstCombine: Check for zero shift amounts before subtracting one causing integer overflow. PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits (those are always undef because we can't represent integer types that large). This should fix assertion failures when building the emulators/xmame port. Reported by: bapt
* Upgrade our copy of llvm/clang to 3.3 release.dim2013-06-1241-1056/+3231
| | | | | | Release notes are still in the works, these will follow soon. MFC after: 1 month
* Pull in r182656 from upstream llvm trunk:dim2013-05-261-1/+4
| | | | | | | | | | | | | | | | | | LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases. Fixes PR16139. This should fix clang assertion failures when optimizing at -O3, similar to: Assertion failed: (TheLoop->getLoopPreheader() && "No preheader!!"), function canVectorize, file contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp, line 2171. Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de> PR: ports/178332, ports/178977 MFC after: 3 days
* Pull in r181286 from upstream llvm trunk:dim2013-05-131-5/+6
| | | | | | | | | | | | | LoopVectorize: getConsecutiveVector must respect signed arithmetic We were passing an i32 to ConstantInt::get where an i64 was needed and we must also pass the sign if we pass negatives numbers. The start index passed to getConsecutiveVector must also be signed. Should fix PR15882. This should fix Firefox crashes some people have been reporting, when it is compiled with -O3.
* Pull in r180121 from upstream llvm trunk:dim2013-04-231-4/+4
| | | | | | | | | | | | | | | LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make sure that the order in which the elements are scalarized is the same as the original order. This fixes a miscompilation in FreeBSD's regex library. This should fix lib/libc/regex/regcomp.c at -O3 with clang 3.3 r178860 on CPUs with SSE. Before this change, the vectorizer could incorrectly rearrange the second loop in computejumps(), leading to possibly invalid entries in the re_gets::charjump table. The net result was that for example "sed s/@CC@/foo/" failed to work correctly, leading to trouble with many configure scripts.
* Upgrade our copy of llvm/clang to trunk r178860, in preparation of thedim2013-04-12128-11722/+20331
| | | | | | | | | upcoming 3.3 release (branching and freezing expected in a few weeks). Preliminary release notes can be found at the usual location: <http://llvm.org/docs/ReleaseNotes.html> An MFC is planned once the actual 3.3 release is finished.
* Upgrade our copy of llvm/clang to 3.2 release.dim2012-12-231-2/+5
| | | | | | | | | | Release notes for llvm: http://llvm.org/releases/3.2/docs/ReleaseNotes.html Release notes for clang: http://llvm.org/releases/3.2/tools/clang/docs/ReleaseNotes.html MFC after: 2 weeks
* Pull in r170353 from upstream llvm trunk:dim2012-12-221-1/+1
| | | | | | | | | | | | | | | | Fix another SROA crasher, PR14601. This was a silly oversight, we weren't pruning allocas which were used by variable-length memory intrinsics from the set that could be widened and promoted as integers. Fix that. This should fix the following assertion failure: Assertion failed: (CanSROA), function visitUsers, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SROA.cpp, line 2395. Reported by: gerald
* Upgrade our copy of llvm/clang to r168974, from upstream's release_32dim2012-12-0387-2942/+12485
| | | | | branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
* Upgrade our copy of llvm/clang to trunk r162107. With thanks todim2012-08-2073-3059/+5616
| | | | Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
* Upgrade our copy of llvm/clang to r155985, from upstream's release_31dim2012-05-039-56/+190
| | | | | | | branch. This brings us very close to the 3.1 release, which is planned for May 14th. MFC after: 2 weeks
* Upgrade our copy of llvm/clang to trunk r154661, in preparation of thedim2012-04-1681-4231/+10081
| | | | | | | upcoming 3.1 release (expected in a few weeks). Preliminary release notes can be found at: <http://llvm.org/docs/ReleaseNotes.html> MFC after: 2 weeks
* Upgrade our copy of llvm/clang to 3.0 release. Release notes can bedim2011-12-091-3/+4
| | | | | | found at: http://llvm.org/releases/3.0/docs/ReleaseNotes.html MFC after: 1 week
* Upgrade our copy of llvm/clang to r142614, from upstream's release_30dim2011-10-2276-3829/+5327
| | | | | | | branch. This brings us very close to the 3.0 release, which is expected in a week or two. MFC after: 1 week
* Upgrade our copy of llvm/clang to r135360, from upstream's trunk.dim2011-07-1752-1610/+5783
|
* Upgrade our copy of llvm/clang to r132879, from upstream's trunk.dim2011-06-1237-659/+2127
|
* Upgrade our copy of llvm/clang to r130700, from upstream's trunk.dim2011-05-0269-1690/+3036
|
* Update llvm/clang to trunk r126547.dim2011-02-278-729/+768
| | | | | | | | | | | | | | There are several bugfixes in this update, but the most important one is to ensure __start_ and __stop_ symbols for linker sets and kernel module metadata are always emitted in object files: http://llvm.org/bugs/show_bug.cgi?id=9292 Before this fix, if you compiled kernel modules with clang, they would not be properly processed by kldxref, and if they had any dependencies, the kernel would fail to load those. Another problem occurred when attempting to mount a tmpfs filesystem, which would result in 'operation not supported by device'.
* Upgrade our copy of llvm/clang to r126079, from upstream's trunk.dim2011-02-20102-8353/+12551
| | | | | This contains many improvements, primarily better C++ support, an integrated assembler for x86 and support for -pg.
* Remove more unneeded files and directories from contrib/llvm. Thisdim2010-10-1115-299/+0
| | | | | | | still allows us to build tblgen and clang, and further reduces the footprint in the tree. Approved by: rpaulo (mentor)
* Upgrade our Clang in base to r114020, from upstream's release_28 branch.dim2010-09-2089-3204/+2705
| | | | Approved-by: rpaulo (mentor)
* Upgrade our Clang in base to r108428.ed2010-07-2064-1111/+1418
| | | | | | | | | This commit merges the latest LLVM sources from the vendor space. It also updates the build glue to match the new sources. Clang's version number is changed to match LLVM's, which means /usr/include/clang/2.0 has been renamed to /usr/include/clang/2.8. Obtained from: projects/clangbsd
* Import LLVM/clang from vendor stripped of docs/ test/ website/ www/ examples/rdivacky2010-06-09113-0/+62844
in llvm/ and/or llvm/contrib/clang/ respectively. Approved by: ed (mentor) Approved by: core
OpenPOWER on IntegriCloud