summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Target/X86
Commit message (Collapse)AuthorAgeFilesLines
* MFC r304319:dim2016-08-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=btver1. Approved by: re (kib) Reported by: Michel Depeige <demik+freebsd@lostwave.net> PR: 211864
* Pull in r271548 from upstream llvm trunk (by me):dim2016-06-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Only attempt to detect AVG if SSE2 is available Summary: In PR29973 Sanjay Patel reported an assertion failure when a certain loop was optimized, for a target without SSE2 support. It turned out this was because of the AVG pattern detection introduced in rL253952. Prevent the assertion failure by bailing out early in `detectAVGPattern()`, if the target does not support SSE2. Also add a minimized test case. Reviewers: congh, eli.friedman, spatel Subscribers: emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D20905 This should fix assertion failures ("Requires at least SSE2!") when building the games/0ad port with CPUTYPE=pentium3. Reported by: madpilot
* Pull in r264465 from upstream llvm trunk (by David Majnemer):dim2016-03-261-1/+1
| | | | | | | | | | | | | | | [X86] Emit a proper ADJCALLSTACKDOWN in EmitLoweredTLSAddr We forgot to add the second machine operand to our ADJCALLSTACKDOWN, resulting in crashes in PEI. This fixes PR27071. This should fix an assertion failure during buildworld, when using -Os, and targeting either i386 directly, or building the 32-bit libraries on amd64. Reported by: Eric Camachat <eric.camachat@gmail.com>
* Update llvm and clang to release_38 branch r261684.dim2016-02-243-2/+39
|
* Undo r295543, since the shrink wrapping bug was fixed upstream by Davidedim2016-02-241-4/+0
| | | | Italiano and Quentin Colombet.
* Update llvm and clang to release_38 branch r261369.dim2016-02-213-40/+21
|
* Update llvm, clang and lldb to release_38 branch r260756.dim2016-02-131-41/+24
|
* For now, disable shrink-wrapping (a new optimization pass that computesdim2016-02-111-0/+4
| | | | | | | the safe point to insert the prologue and epilogue of the function) on X86. This prevents problems with some functions using TLS, such as in jemalloc, and which was the cause for Address Sanitizer crashes. The correct fix is still being discussed upstream.
* Update llvm, clang and lldb to release_38 branch r258968.dim2016-01-271-1/+2
|
* Update llvm and clang to release_38 branch r258549.dim2016-01-223-7/+24
|
* Update llvm, clang and lldb to release_38 branch r257836.dim2016-01-162-7/+8
|
* Update llvm, clang and lldb to trunk r257626, and update build glue.dim2016-01-1416-265/+784
|
* Update llvm to trunk r256945.dim2016-01-0621-370/+535
|
* Update llvm to trunk r256633.dim2015-12-3073-7550/+15183
|
* 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).
* Update llvm, clang and lldb to 3.7.0 release.dim2015-09-066-76/+90
|
* Update llvm/clang to r242221.dim2015-08-1230-810/+1669
|
* Update llvm/clang to r241361.dim2015-07-0555-1194/+1741
|
* Update llvm/clang to r240225.dim2015-06-2351-732/+1477
|
* Update Makefiles and other build glue for llvm/clang 3.7.0, as of trunkdim2015-06-1036-1095/+1808
| | | | r239412.
* Merge llvm trunk r238337 from ^/vendor/llvm/dist, resolve conflicts, anddim2015-05-2778-10814/+12009
| | | | preserve our customizations, where necessary.
* Upgrade our copy of clang and llvm to 3.6.1 release.dim2015-05-255-102/+119
| | | | | | | | | | | | | | | | | | | | | | | | 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 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-146-17/+15
| | | | ^/vendor/clang/dist, resolve conflicts, and update patches README.
* 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-313-46/+86
| | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromdim2015-01-2591-10539/+18635
| | | | ^/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-181-0/+3
| | | | | | | | | | | | | | 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
* Merge llvm 3.5.0 release from ^/vendor/llvm/dist, resolve conflicts, anddim2014-11-2493-11282/+19564
| | | | 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
* Upgrade our copy of llvm/clang to 3.4.1 release. This release containsdim2014-05-126-37/+95
| | | | | | | | | | | | | | | 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
* Upgrade our copy of llvm/clang to 3.4 release. This version supportsdim2014-02-1673-4254/+12984
| | | | | | | | | | | | | | | | | 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
* Revert r258455 for now, as it apparently causes miscompilation in somedim2013-11-221-8/+14
| | | | | situations. Until this is fully resolved, the X.org workaround in ports still needs to take place.
* Pull in r195318 from upstream llvm trunk:dim2013-11-211-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The basic problem is that some mainstream programs cannot deal with the way clang optimizes tail calls, as in this example: int foo(void); int bar(void) { return foo(); } where the call is transformed to: calll .L0$pb .L0$pb: popl %eax .Ltmp0: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %eax movl foo@GOT(%eax), %eax popl %ebp jmpl *%eax # TAILCALL However, the GOT references must all be resolved at dlopen() time, and so this approach cannot be used with lazy dynamic linking (e.g. using RTLD_LAZY), which usually populates the PLT with stubs that perform the actual resolving. This patch changes X86TargetLowering::LowerCall() to skip tail call optimization, if the called function is a global or external symbol. This fixes problems with loading X.org driver modules, which could occur when X.org was compiled on i386 with tailcall optimization on, for which ports r312583 was committed as a workaround. After this change, the workaround can be removed. MFC after: 3 days
* Pull in r192064 from upstream llvm trunk:dim2013-10-061-0/+4
| | | | | | | | | | | | | | X86: Don't fold spills into SSE operations if the stack is unaligned. Regalloc can emit unaligned spills nowadays, but we can't fold the spills into SSE ops if we can't guarantee alignment. PR12250. This fixes unaligned SSE accesses (leading to a SIGBUS) which could occur in the ffmpeg ports. Approved by: re (kib) Reported by: tijl MFC after: 3 days
* Pull in r189644 from upstream llvm trunk:dim2013-10-034-25/+45
| | | | | | | | | | | | Add ms_abi and sysv_abi attribute handling. Based on a patch by Benno Rice! This will help to develop EFI support. Approved by: re (kib) Verified by: benno MFC after: 1 week
* Pull in r191711 from upstream llvm trunk:dim2013-10-011-0/+9
| | | | | | | | | | | | | | | | | | | | | The X86FixupLEAs pass for Intel Atom must not call convertToThreeAddress on ADD16rr opcodes, if src1 != src, since that would cause convertToThreeAddress to try to create a virtual register. This is not permitted after register allocation, which is when the X86FixupLEAs pass runs. This patch fixes PR16785. Pull in r191715 from upstream llvm trunk: Forgot to add a break statement. This should enable building the x11-toolskits/libXaw port with CPUTYPE=atom. Approved by: re (gjb) Reported by: Kenta Suzumoto <kentas@hush.com> MFC after: 3 days
* Pull in r191165 from upstream llvm trunk:dim2013-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | ISelDAG: spot chain cycles involving MachineNodes Previously, the DAGISel function WalkChainUsers was spotting that it had entered already-selected territory by whether a node was a MachineNode (amongst other things). Since it's fairly common practice to insert MachineNodes during ISelLowering, this was not the correct check. Looking around, it seems that other nodes get their NodeId set to -1 upon selection, so this makes sure the same thing happens to all MachineNodes and uses that characteristic to determine whether we should stop looking for a loop during selection. This should fix PR15840. Specifically, this fixes the long-standing assertion failure when compiling the multimedia/gstreamer port on i386. Thanks to Tijl Coosemans for his help in getting upstream to fix it. Approved by: re (marius)
* Import llvm r187614 (git 44c8e34), for lldb's use:emaste2013-08-242-7/+5
| | | | | | | | | | | | Author: Daniel Malea <daniel.malea@intel.com> Date: Thu Aug 1 21:18:16 2013 +0000 Fixed the Intel-syntax X86 disassembler to respect the (existing) option for hexadecimal immediates, to match AT&T syntax. This also brings a new option for C-vs-MASM-style hex. Patch by Richard Mitton Reviewed: http://llvm-reviews.chandlerc.com/D1243
* Pull in r181620 from llvm trunk:dim2013-06-142-27/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ms-inline asm] Fix a crasher when we fail on a direct match. The issue was that the MatchingInlineAsm and VariantID args to the MatchInstructionImpl function weren't being set properly. Specifically, when parsing intel syntax, the parser thought it was parsing inline assembly in the at&t dialect; that will never be the case. The crash was caused when the emitter tried to emit the instruction, but the operands weren't set. When parsing inline assembly we only set the opcode, not the operands, which is used to lookup the instruction descriptor. rdar://13854391 and PR15945 Also, this commit reverts r176036. Now that we're correctly parsing the intel syntax the pushad/popad don't match properly. I've reimplemented that fix using a MnemonicAlias. Pull in r183907 from llvm trunk: X86: Make the cmov aliases work with intel syntax too. These commits make a number of Intel-style inline assembly mnemonics aliases (occurring in several ports) work properly, which could cause assertions otherwise. Reported by: kwm, bapt
* Upgrade our copy of llvm/clang to 3.3 release.dim2013-06-1226-803/+1773
| | | | | | Release notes are still in the works, these will follow soon. MFC after: 1 month
* Upgrade our copy of llvm/clang to trunk r178860, in preparation of thedim2013-04-1267-5353/+8062
| | | | | | | | | 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.
* Pull in r175962 from upstream llvm trunk:dim2013-02-231-6/+8
| | | | | | | | | | | | X86: Disable cmov-memory patterns on subtargets without cmov. Fixes PR15115. For the i386 arch, this should enable cmov instructions only on -march=pentiumpro and higher. Since our default CPU is i486, cmov instructions will now be disabled by default. MFC after: 1 week
* Pull in r175057 from upstream llvm trunk:dim2013-02-151-0/+8
| | | | | | | | | | | | | X86: Disable generation of rep;movsl when %esi is used as a base pointer. This happens when there is both stack realignment and a dynamic alloca in the function. If we overwrite %esi (rep;movsl uses fixed registers) we'll lose the base pointer and the next register spill will write into oblivion. Fixes PR15249 and unbreaks firefox on i386/freebsd. Mozilla uses dynamic allocas and freebsd a 4 byte stack alignment. MFC after: 1 week
* Upgrade our copy of llvm/clang to r168974, from upstream's release_32dim2012-12-0358-3754/+5675
| | | | | branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
* Reduce LLVM's default stack alignment for i386 from 16 to 4 bytes, asdim2012-11-091-4/+4
| | | | | | | the FreeBSD ABI requires. This is essentially a revert of upstream llvm commit r126226, and it will be reverted by upstream too. MFC after: 1 week
* Pull in r165377 from upstream llvm trunk:dim2012-10-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | X86: fcmov doesn't handle all possible EFLAGS, fall back to a branch for the others. Otherwise it will try to use SSE patterns and fail horribly if sse is disabled. Fixes PR14035. This should fix the following assertion failure: Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg, file contrib/llvm/lib/Target/X86/X86FloatingPoint.cpp, line 330. which can show up when compiling contrib/compiler-rt, using -march=i686 through -march=pentium3 (CPU's which do support fcmov, but don't support SSE2). MFC after: 1 week
OpenPOWER on IntegriCloud