summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
Commit message (Collapse)AuthorAgeFilesLines
* MFC r304530:dim2016-08-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r265122 from upstream llvm trunk (by James Molloy): Fix for pr24346: arm asm label calculation error in sub Some ARM instructions encode 32-bit immediates as a 8-bit integer (0-255) and a 4-bit rotation (0-30, even) in its least significant 12 bits. The original fixup, FK_Data_4, patches the instruction by the value bit-to-bit, regardless of the encoding. For example, assuming the label L1 and L2 are 0x0 and 0x104 respectively, the following instruction: add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260 would be assembled to the following, which adds 1 to r0, instead of 260: e2800104 add r0, r0, #4, 2 ; equivalently 1 The new fixup kind fixup_arm_mod_imm takes care of the encoding: e2800f41 add r0, r0, #260 Patch by Ting-Yuan Huang! This fixes label calculation for ARM assembly, and is needed to enable ARM assembly sources for OpenSSL. Approved by: re (kib) Requested by: jkim
* Update llvm to trunk r256633.dim2015-12-301-50/+339
|
* Update llvm/clang to r240225.dim2015-06-231-12/+11
|
* Update Makefiles and other build glue for llvm/clang 3.7.0, as of trunkdim2015-06-101-9/+8
| | | | r239412.
* Merge llvm trunk r238337 from ^/vendor/llvm/dist, resolve conflicts, anddim2015-05-271-14/+16
| | | | preserve our customizations, where necessary.
* Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromdim2015-01-251-246/+186
| | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Merge llvm 3.5.0 release from ^/vendor/llvm/dist, resolve conflicts, anddim2014-11-241-142/+309
| | | | preserve our customizations, where necessary.
* Upgrade our copy of llvm/clang to 3.4 release. This version supportsdim2014-02-161-24/+29
| | | | | | | | | | | | | | | | | 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
* Upgrade our copy of llvm/clang to trunk r178860, in preparation of thedim2013-04-121-87/+66
| | | | | | | | | 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 r168974, from upstream's release_32dim2012-12-031-1/+12
| | | | | branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
* Pull in r164132 from upstream llvm trunk:dim2012-10-101-1/+1
| | | | | | | | | | | | | | | | | When creating MCAsmBackend pass the CPU string as well. In X86AsmBackend store this and use it to not emit long nops when the CPU is geode which doesnt support them. Fixes PR11212. Pull in r164133 from upstream clang trunk: Follow up on llvm r164132. This should prevent illegal instructions when building world on Geode CPUs (e.g. Soekris). MFC after: 3 days
* Upgrade our copy of llvm/clang to trunk r162107. With thanks todim2012-08-201-66/+111
| | | | Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
* Upgrade our copy of llvm/clang to trunk r154661, in preparation of thedim2012-04-161-29/+151
| | | | | | | 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 r142614, from upstream's release_30dim2011-10-221-0/+531
branch. This brings us very close to the 3.0 release, which is expected in a week or two. MFC after: 1 week
OpenPOWER on IntegriCloud