summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
* Upgrade our copies of clang and llvm to 3.7.1 release. This is adim2015-12-2529-82/+416
| | | | | | | 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.
* Pull in r250085 from upstream llvm trunk (by Andrea Di Biagio):dim2015-10-131-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [x86] Fix wrong lowering of vsetcc nodes (PR25080). Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong assumption that for non-AVX512 targets, the source type and destination type of a type-legalized setcc node were always the same type. This assumption was unfortunately incorrect; the type legalizer is not always able to promote the return type of a setcc to the same type as the first operand of a setcc. In the case of a vsetcc node, the legalizer firstly checks if the first input operand has a legal type. If so, then it promotes the return type of the vsetcc to that same type. Otherwise, the return type is promoted to the 'next legal type', which, for vectors of MVT::i1 is always a 128-bit integer vector type. Example (-mattr=+avx): %0 = trunc <8 x i32> %a to <8 x i23> %1 = icmp eq <8 x i23> %0, zeroinitializer The initial selection dag for the code above is: v8i1 = setcc t5, t7, seteq:ch t5: v8i23 = truncate t2 t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1 t7: v8i32 = build_vector of all zeroes. The type legalizer would firstly check if 't5' has a legal type. If so, then it would reuse that same type to promote the return type of the setcc node. Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to promote the return type of the setcc node. Consequently, the setcc return type is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the following dag node: v8i16 = setcc t32, t25, seteq:ch where t32 and t25 are now values of type v8i32. Before this patch, function LowerVSETCC would have wrongly expanded the setcc to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an instruction. In our case, ISel would have matched a VPCMPEQWrr: t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25 However, t36 and t25 are both VR256, while the result type is instead of class VR128. This inconsistency ended up causing the insertion of COPY instructions like this: %vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3 Which is an invalid full copy (not a sub register copy). Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy instruction" in the attempt to expand the malformed pseudo COPY instructions. This patch fixes the problem adding the missing logic in LowerVSETCC to handle the corner case of a setcc with 128-bit return type and 256-bit operand type. This problem was originally reported by Dimitry as PR25080. It has been latent for a very long time. I have added the minimal reproducible from that bugzilla as test setcc-lowering.ll. Differential Revision: http://reviews.llvm.org/D13660 This should fix the "Cannot emit physreg copy instruction" errors when compiling contrib/wpa/src/common/ieee802_11_common.c, and CPUTYPE is set to a CPU supporting AVX (e.g. sandybridge, ivybridge).
* The R600 target got renamed to AMDGPU, but I missed deleting the olddim2015-09-21106-44148/+0
| | | | directory during the vendor import. Delete it now.
* Update llvm, clang and lldb to 3.7.0 release.dim2015-09-0638-412/+580
|
* Update llvm/clang to r242221.dim2015-08-12258-3804/+12036
|
* Update llvm/clang to r241361.dim2015-07-05413-2255/+6769
|
* Update llvm/clang to r240225.dim2015-06-23491-2465/+48320
|
* Update Makefiles and other build glue for llvm/clang 3.7.0, as of trunkdim2015-06-10258-3278/+11268
| | | | r239412.
* Merge llvm trunk r238337 from ^/vendor/llvm/dist, resolve conflicts, anddim2015-05-27733-41918/+66955
| | | | preserve our customizations, where necessary.
* Upgrade our copy of clang and llvm to 3.6.1 release.dim2015-05-2555-989/+1592
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* llvm: Backport upstream r229195 to fix arm64 TLS relocationsemaste2015-03-307-135/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As is described at http://llvm.org/bugs/show_bug.cgi?id=22408, the GNU linkers ld.bfd and ld.gold currently only support a subset of the whole range of AArch64 ELF TLS relocations. Furthermore, they assume that some of the code sequences to access thread-local variables are produced in a very specific sequence. When the sequence is not as the linker expects, it can silently mis-relaxe/mis-optimize the instructions. Even if that wouldn't be the case, it's good to produce the exact sequence, as that ensures that linkers can perform optimizing relaxations. This patch: * implements support for 16MiB TLS area size instead of 4GiB TLS area size. Ideally clang would grow an -mtls-size option to allow support for both, but that's not part of this patch. * by default doesn't produce local dynamic access patterns, as even modern ld.bfd and ld.gold linkers do not support the associated relocations. An option (-aarch64-elf-ldtls-generation) is added to enable generation of local dynamic code sequence, but is off by default. * makes sure that the exact expected code sequence for local dynamic and general dynamic accesses is produced, by making use of a new pseudo instruction. The patch also removes two (AArch64ISD::TLSDESC_BLR, AArch64ISD::TLSDESC_CALL) pre-existing AArch64-specific pseudo SDNode instructions that are superseded by the new one (TLSDESC_CALLSEQ). Submitted by: Kristof Beyls Differential Revision: https://reviews.freebsd.org/D2175
* Pull in r230348 from upstream llvm trunk (by Tim Northover):dim2015-03-233-61/+100
| | | | | | | | | | | | | | | | | ARM: treat [N x i32] and [N x i64] as AAPCS composite types The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments. Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency. This fixes a possible "Unexpected member type for HA" error when compiling lib/msun/bsdsrc/b_tgamma.c for armv6. Reported by: Jakub Palider <jpa@semihalf.com>
* Merge llvm 3.6.0rc4 from ^/vendor/llvm/dist, merge clang 3.6.0rc4 fromdim2015-02-191-0/+164
| | | | ^/vendor/clang/dist, resolve conflicts, and update patches.
* Merge llvm 3.6.0rc3 from ^/vendor/llvm/dist, merge clang 3.6.0rc3 fromdim2015-02-1414-179/+146
| | | | ^/vendor/clang/dist, resolve conflicts, and update patches README.
* Pull in r227089 from upstream llvm trunk (by Vasileios Kalintiris):dim2015-02-074-30/+66
| | | | | | | | | | | | | | | | | | | | | | | | [mips] Enable arithmetic and binary operations for the i128 data type. Summary: This patch adds support for some operations that were missing from 128-bit integer types (add/sub/mul/sdiv/udiv... etc.). With these changes we can support the __int128_t and __uint128_t data types from C/C++. Depends on D7125 Reviewers: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7143 This fixes "error in backend" messages, when compiling parts of compiler-rt using 128-bit integer types for mips64. Reported by: sbruno PR: 197259
* Pull in r227752 from upstream llvm trunk (by Michael Kuperstein):dim2015-02-0211-135/+534
| | | | | | | | | | | | | | | | | [X86] Convert esp-relative movs of function arguments to pushes, step 2 This moves the transformation introduced in r223757 into a separate MI pass. This allows it to cover many more cases (not only cases where there must be a reserved call frame), and perform rudimentary call folding. It still doesn't have a heuristic, so it is enabled only for optsize/minsize, with stack alignment <= 8, where it ought to be a fairly clear win. (Re-commit of r227728) Differential Revision: http://reviews.llvm.org/D6789 This helps to get sys/boot/i386/boot2 below the required size again, when optimizing with -Oz.
* Merge llvm 3.6.0rc2 from ^/vendor/llvm/dist, merge clang 3.6.0rc2 fromdim2015-01-3147-495/+794
| | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Merge ^/head r277719 through 277776.dim2015-01-261-3/+7
|\
| * Pull in r226664 from upstream llvm trunk (by Tim Northover):dim2015-01-261-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | AArch64: add backend option to reserve x18 (platform register) AAPCS64 says that it's up to the platform to specify whether x18 is reserved, and a first step on that way is to add a flag controlling it. From: Andrew Turner <andrew@fubar.geek.nz> Requested by: andrew
* | Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromdim2015-01-25732-31982/+66161
|/ | | | ^/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-1837-751/+1381
| | | | | | | | | | | | | | 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 r222292 from upstream llvm trunk (by Weiming Zhao):dim2015-01-071-0/+3
| | | | | | | | [Aarch64] Customer lowering of CTPOP to SIMD should check for NEON availability This ensures llvm's AArch64 backend does not emit floating point instructions if they are disabled.
* Pull in r222587 from upstream llvm trunk (by Jörg Sonnenberger):dim2015-01-021-5/+25
| | | | | | | | | | | Fix transformation of add with pc argument to adr for non-immediate arguments. This fixes an "Unimplemented" error when assembling certain ARM add instructions with pc-relative arguments. Reported by: sbruno PR: 196412, 196423
* Pull in r224890 from upstream llvm trunk (by David Majnemer):dim2014-12-281-0/+18
| | | | | | | | | | | | | | | | | | PowerPC: CTR shouldn't fire if a TLS call is in the loop Determining the address of a TLS variable results in a function call in certain TLS models. This means that a simple ICmpInst might actually result in invalidating the CTR register. In such cases, do not attempt to rely on the CTR register for loop optimization purposes. This fixes PR22034. Differential Revision: http://reviews.llvm.org/D6786 This fixes a "Invalid PPC CTR loop" error when compiling parts of libc for PowerPC-32.
* Pull in r221703 from upstream llvm trunk (by Bill Schmidt):dim2014-12-277-125/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PowerPC] Replace foul hackery with real calls to __tls_get_addr My original support for the general dynamic and local dynamic TLS models contained some fairly obtuse hacks to generate calls to __tls_get_addr when lowering a TargetGlobalAddress. Rather than generating real calls, special GET_TLS_ADDR nodes were used to wrap the calls and only reveal them at assembly time. I attempted to provide correct parameter and return values by chaining CopyToReg and CopyFromReg nodes onto the GET_TLS_ADDR nodes, but this was also not fully correct. Problems were seen with two back-to-back stores to TLS variables, where the call sequences ended up overlapping with unhappy results. Additionally, since these weren't real calls, the proper register side effects of a call were not recorded, so clobbered values were kept live across the calls. The proper thing to do is to lower these into calls in the first place. This is relatively straightforward; see the changes to PPCTargetLowering::LowerGlobalTLSAddress() in PPCISelLowering.cpp. The changes here are standard call lowering, except that we need to track the fact that these calls will require a relocation. This is done by adding a machine operand flag of MO_TLSLD or MO_TLSGD to the TargetGlobalAddress operand that appears earlier in the sequence. The calls to LowerCallTo() eventually find their way to LowerCall_64SVR4() or LowerCall_32SVR4(), which call FinishCall(), which calls PrepareCall(). In PrepareCall(), we detect the calls to __tls_get_addr and immediately snag the TargetGlobalTLSAddress with the annotated relocation information. This becomes an extra operand on the call following the callee, which is expected for nodes of type tlscall. We change the call opcode to CALL_TLS for this case. Back in FinishCall(), we change it again to CALL_NOP_TLS for 64-bit only, since we require a TOC-restore nop following the call for the 64-bit ABIs. During selection, patterns in PPCInstrInfo.td and PPCInstr64Bit.td convert the CALL_TLS nodes into BL_TLS nodes, and convert the CALL_NOP_TLS nodes into BL8_NOP_TLS nodes. This replaces the code removed from PPCAsmPrinter.cpp, as the BL_TLS or BL8_NOP_TLS nodes can now be emitted normally using their patterns and the associated printTLSCall print method. Finally, as a result of these changes, all references to get-tls-addr in its various guises are no longer used, so they have been removed. There are existing TLS tests to verify the changes haven't messed anything up). I've added one new test that verifies that the problem with the original code has been fixed. This fixes a fatal "Bad machine code" error when compiling parts of libgomp for 32-bit PowerPC.
* Pull in r214284 from upstream llvm trunk (by Hal Finkel):dim2014-12-255-63/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PowerPC] Add JMP_SLOT relocation definitions This will be required by upcoming patches for LLDB support. Patch by Justin Hibbits! Pull in r221510 from upstream llvm trunk (by Justin Hibbits): Add Position-independent Code model Module API. Summary: This makes PIC levels a Module flag attribute, which can be queried by the backend. The flag is named `PIC Level`, and can have a value of: 0 - Backend-default 1 - Small-model (-fpic) 2 - Large-model (-fPIC) These match the `-pic-level' command line argument for clang, and the value of the preprocessor macro `__PIC__'. Test Plan: New flags tests specific for the 'PIC Level' module flag. Tests to be added as part of a future commit for PowerPC, which will use this new API. Reviewers: rafael, echristo Reviewed By: rafael, echristo Subscribers: rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D5882 Pull in r221791 from upstream llvm trunk (by Justin Hibbits): Add support for small-model PIC for PowerPC. Summary: Large-model was added first. With the addition of support for multiple PIC models in LLVM, now add small-model PIC for 32-bit PowerPC, SysV4 ABI. This generates more optimal code, for shared libraries with less than about 16380 data objects. Test Plan: Test cases added or updated Reviewers: joerg, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, mcrosier, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5399 Together, these changes implement small-model PIC support for PowerPC. Thanks to Justin Hibbits and Roman Divacky for their assistance in getting this working.
* Pull in r223147, r223255 and r223390 from upstream llvm trunk (by Romandim2014-12-091-0/+14
| | | | | | | | | | | | | | | Divacky): Introduce CPUStringIsValid() into MCSubtargetInfo and use it for ARM .cpu parsing. Previously .cpu directive in ARM assembler didnt switch to the new CPU and therefore acted as a nop. This implemented real action for .cpu and eg. allows to assembler FreeBSD kernel with -integrated-as. Change the name to be in style. Add a FIXME as requested by Renato Golin.
* For now, enable the clrex instruction for armv6, until upstreamdim2014-12-011-1/+1
| | | | | | implements this properly. Submitted by: andrew
* Pull in r215811 from upstream llvm trunk (by Nico Weber):dim2014-11-301-0/+36
| | | | | | | | | | | | | arm asm: Let .fpu enable instructions, PR20447. I'm not very happy with duplicating the fpu->feature mapping in ARMAsmParser.cpp and in clang's driver. See the bug for a patch that doesn't do that, and the review thread [1] for why this duplication exists. 1: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/231052.html This makes the .fpu directive work properly, so we can successfully assemble several .S files using the directive, under lib/libc/arm.
* Pull in r214802 from upstream llvm trunk (by Renato Golin):dim2014-11-291-3/+7
| | | | | | | | | | | | | Allow CP10/CP11 operations on ARMv5/v6 Those registers are VFP/NEON and vector instructions should be used instead, but old cores rely on those co-processors to enable VFP unwinding. This change was prompted by the libc++abi's unwinding routine and is also present in many legacy low-level bare-metal code that we ought to compile/assemble. Fixing bug PR20025 and allowing PR20529 to proceed with a fix in libc++abi. This enables assembling certain ARM instructions used in libgcc.
* Cleanup upstream build infrastructure files that we don't use.dim2014-11-243-42/+0
|
* Merge llvm 3.5.0 release from ^/vendor/llvm/dist, resolve conflicts, anddim2014-11-24800-67667/+142804
| | | | preserve our customizations, where necessary.
* Pull in r217410 from upstream llvm trunk (by Bob Wilson):dim2014-09-141-2/+2
| | | | | | | | | | | | | | | | | | | | Set trunc store action to Expand for all X86 targets. When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas with SSE2 it would return Expand. And since the Target doesn't seem to actually handle a truncstore for double -> float, it would just output a store of a full double in the space for a float hence overwriting other bits on the stack. Patch by Luqman Aden! This should fix clang -O0 on i386 assigning garbage to floats, in certain scenarios. PR: 187437 Submitted by: cebd@gmail.com Obtained from: http://llvm.org/viewvc/llvm-project?rev=217410&view=rev MFC after: 3 days
* Apparently, the patch commited in svn r271029 doesn't actually do anyting,sbruno2014-09-031-1/+2
| | | | | | | so we still need to modify the code in place. Pointed out by emaste. MFC after: 2 days Relnotes: yes
* Do not direct commit to contrib/llvm. Make the change a patch file instead.sbruno2014-09-031-2/+1
| | | | | | | | | | | | | | | | | | | | Reverts 271025 but still functionally patches it. Original intent is still the same. Pointed out by rdivacky. MFV: Only emit movw on ARMv6T2 Building for the FreeBSD default target ARMv6 was emitting movw ASM on certain test cases (found building qmake4/5 for ARM). Don't do that, moreover, the AS in base doesn't understand this instruction for this target. One would need to use --integrated-as to get this to build if desired. http://llvm.org/viewvc/llvm-project?view=revision&revision=216989 Submitted by: ian Reviewed by: dim Obtained from: llvm.org MFC after: 2 days Relnotes: yes
* MFV: Only emit movw on ARMv6T2sbruno2014-09-031-1/+2
| | | | | | | | | | | | | | Building for the FreeBSD default target ARMv6 was emitting movw ASM on certain test cases (found building qmake4/5 for ARM). Don't do that, moreover, the AS in base doesn't understand this instruction for this target. One would need to use --integrated-as to get this to build if desired. http://llvm.org/viewvc/llvm-project?view=revision&revision=216989 Submitted by: ian Reviewed by: dim Obtained from: llvm.org MFC after: 2 days
* Backport r197824, r213427 and r213960 from LLVM trunk:rdivacky2014-08-1816-92/+535
| | | | | | | | | | | | | | | | | | | | | | | | | r197824 | rdivacky | 2013-12-20 19:08:54 +0100 (Fri, 20 Dec 2013) | 2 lines Implement initial-exec TLS for PPC32. r213427 | hfinkel | 2014-07-19 01:29:49 +0200 (Sat, 19 Jul 2014) | 7 lines [PowerPC] 32-bit ELF PIC support This adds initial support for PPC32 ELF PIC (Position Independent Code; the -fPIC variety), thus rectifying a long-standing deficiency in the PowerPC backend. Patch by Justin Hibbits! r213960 | hfinkel | 2014-07-25 19:47:22 +0200 (Fri, 25 Jul 2014) | 3 lines [PowerPC] Support TLS on PPC32/ELF Patch by Justin Hibbits! Reviewed by: jhibbits Approved by: dim
* Fix breakage after r267981.dim2014-06-281-1/+1
| | | | | | Pointy hat to: dim MFC after: 3 days X-MFC-With: r267981
* Pull in r211627 from upstream llvm trunk (by Bill Schmidt):dim2014-06-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | [PPC64] Fix PR20071 (fctiduz generated for targets lacking that instruction) PR20071 identifies a problem in PowerPC's fast-isel implementation for floating-point conversion to integer. The fctiduz instruction was added in Power ISA 2.06 (i.e., Power7 and later). However, this instruction is being generated regardless of which 64-bit PowerPC target is selected. The intent is for fast-isel to punt to DAG selection when this instruction is not available. This patch implements that change. For testing purposes, the existing fast-isel-conversion.ll test adds a RUN line for -mcpu=970 and tests for the expected code generation. Additionally, the existing test fast-isel-conversion-p5.ll was found to be incorrectly expecting the unavailable instruction to be generated. I've removed these test variants since we have adequate coverage in fast-isel-conversion.ll. This is needed to compile clang with debug+asserts on older powerpc64 and ppc970 targets. Requested by: jhibbits MFC after: 3 days
* Upgrade our copy of llvm/clang to 3.4.1 release. This release containsdim2014-05-1240-167/+539
| | | | | | | | | | | | | | | 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
* Pull in r196939 from upstream llvm trunk (by Reid Kleckner):dim2014-03-182-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland "Fix miscompile of MS inline assembly with stack realignment" This re-lands commit r196876, which was reverted in r196879. The tests have been fixed to pass on platforms with a stack alignment larger than 4. Update to clang side tests will land shortly. Pull in r196986 from upstream llvm trunk (by Reid Kleckner): Revert the backend fatal error from r196939 The combination of inline asm, stack realignment, and dynamic allocas turns out to be too common to reject out of hand. ASan inserts empy inline asm fragments and uses aligned allocas. Compiling any trivial function containing a dynamic alloca with ASan is enough to trigger the check. XFAIL the test cases that would be miscompiled and add one that uses the relevant functionality. Pull in r202930 from upstream llvm trunk (by Hans Wennborg): Check for dynamic allocas and inline asm that clobbers sp before building selection dag (PR19012) In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo to make sure that ESI isn't used as a base pointer register before we choose to emit rep movs (which clobbers esi). The problem is that MachineFrameInfo wouldn't know about dynamic allocas or inline asm that clobbers the stack pointer until SelectionDAGBuilder has encountered them. This patch fixes the problem by checking for such things when building the FunctionLoweringInfo. Differential Revision: http://llvm-reviews.chandlerc.com/D2954 Together, these commits fix the problem encountered in the devel/emacs port on the i386 architecture, where a combination of stack realignment, alloca() and memcpy() could incidentally clobber the %esi register, leading to segfaults in the temacs build-time utility. See also: http://llvm.org/PR18171 and http://llvm.org/PR19012 Reported by: ashish PR: ports/183064 MFC after: 1 week
* Repair a few minor mismerges from r262261 in the clang-sparc64 projectdim2014-03-104-85/+1
| | | | | | | branch. This is also to minimize differences with upstream. MFC after: 3 weeks X-MFC-With: r262613
* Pull in r202422 from upstream llvm trunk (by Roman Divacky):dim2014-02-271-17/+8
| | | | | | Lower FNEG just like FABS to fneg[ds] and fmov[ds], thus avoiding expensive libcall. Also, Qp_neg is not implemented on at least FreeBSD. This is also what gcc is doing.
* Pull in r201994 from upstream llvm trunk (by Benjamin Kramer):dim2014-02-232-0/+5
| | | | | | | SPARC: Implement TRAP lowering. Matches what GCC emits. This lets clang emit "ta 5" for trap instructions on sparc64, instead of emitting a call to abort(), making it possible to link the kernel.
* Pull in r201718 from upstream llvm trunk:dim2014-02-201-0/+4
| | | | | | Expand 64bit {SHL,SHR,SRA}_PARTS on sparcv9. Submitted by: rdivacky
* Pull in r200453 from upstream llvm trunk:dim2014-02-202-3/+15
| | | | | | | | | | Implement SPARCv9 atomic_swap_64 with a pseudo. The SWAP instruction only exists in a 32-bit variant, but the 64-bit atomic swap can be implemented in terms of CASX, like the other atomic rmw primitives. Submitted by: rdivacky
* Import a whole bunch of llvm trunk commits to enable self-hosting clangdim2014-02-2038-758/+4438
| | | | | | | | | | | | | | 3.4 on Sparc64 (commit descriptions left out for brevity): r196755 r198028 r198029 r198030 r198145 r198149 r198157 r198565 r199186 r199187 r198280 r198281 r198286 r198480 r198484 r198533 r198567 r198580 r198591 r198592 r198658 r198681 r198738 r198739 r198740 r198893 r198909 r198910 r199014 r199024 r199028 r199031 r199033 r199061 r199775 r199781 r199786 r199940 r199974 r199975 r199977 r200103 r200104 r200112 r200130 r200131 r200141 r200282 r200368 r200373 r200376 r200509 r200617 r200960 r200961 r200962 r200963 r200965 Submitted by: rdivacky
* Upgrade our copy of llvm/clang to 3.4 release. This version supportsdim2014-02-16670-42213/+89786
| | | | | | | | | | | | | | | | | 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 r195679 from upstream llvm trunk:dim2014-01-251-1/+5
| | | | | | | | | | | | | | | | | | Don't use nopl in cpus that don't support it. Patch by Mikulas Patocka. I added the test. I checked that for cpu names that gas knows about, it also doesn't generate nopl. The modified cpus: i686 - there are i686-class CPUs that don't have nopl: Via c3, Transmeta Crusoe, Microsoft VirtualBox - see https://bbs.archlinux.org/viewtopic.php?pid=775414 k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that Via c3 and c3-Nehemiah don't have nopl PR: bin/185777 MFC after: 3 days
* Pull in r183971 from upstream llvm trunk:dim2013-12-251-7/+8
| | | | | | | | | | | | | X86: cvtpi2ps is just an SSE instruction with MMX operands. It has no AVX equivalent. Give it the right register format so we can also emit it when AVX is enabled. This should fix a "Cannot select: intrinsic %llvm.x86.sse.cvtpi2ps" fatal error in clang while building the gnuradio port for amd64. Reported by: db MFC after: 3 days
OpenPOWER on IntegriCloud