summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Target/X86
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Pull in r165878 from upstream llvm trunk:dim2012-10-221-1/+3
| | | | | | | | | X86: Disable long nops for all cpus prior to pentiumpro/i686. This is the safest approach for now. If you think long nops matter a lot for performance, compile with -march=i686 or higher. :) MFC after: 3 days
* Pull in r164132 from upstream llvm trunk:dim2012-10-102-26/+34
| | | | | | | | | | | | | | | | | 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
* Pull in r163710 from upstream llvm trunk:dim2012-10-101-0/+1
| | | | | | Add support for AMD Geode. MFC after: 3 days
* Pull in r163967 from upstream llvm trunk:dim2012-09-151-0/+2
| | | | | | | | | X86: Emitting x87 fsin/fcos for sinf/cosf is not safe without unsafe fp math. This should make clang emit calls to libm for sinf/cosf by default. MFC after: 1 week
* Upgrade our copy of llvm/clang to trunk r162107. With thanks todim2012-08-2062-3672/+7369
| | | | Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
* Upgrade our copy of llvm/clang to r155985, from upstream's release_31dim2012-05-038-60/+129
| | | | | | | 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-1682-7365/+13392
| | | | | | | 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
* Pull in r148240 from upstream llvm trunk:dim2012-01-201-1/+1
| | | | | | | | | | | Make sure the non-SSE lowering for fences correctly clobbers EFLAGS. PR11768. In particular, this fixes segfaults during the build of devel/icu on i386. The __sync_synchronize() builtin used for implementing icu's internal barrier could lead to incorrect behaviour. MFC after: 3 days
* Upgrade our copy of llvm/clang to 3.0 release. Release notes can bedim2011-12-091-9/+24
| | | | | | 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-2264-5241/+8851
| | | | | | | 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-1746-1067/+2300
|
* Upgrade our copy of llvm/clang to r132879, from upstream's trunk.dim2011-06-1225-1003/+1170
|
* Upgrade our copy of llvm/clang to r130700, from upstream's trunk.dim2011-05-0245-1196/+2235
|
* Update llvm/clang to trunk r126547.dim2011-02-2714-37/+97
| | | | | | | | | | | | | | 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-2070-10355/+11269
| | | | | 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-1117-3555/+0
| | | | | | | still allows us to build tblgen and clang, and further reduces the footprint in the tree. Approved by: rpaulo (mentor)
* Upgrade Clang and LLVM to the 2.8 release. See here for release notes:dim2010-10-071-11/+4
| | | | | | http://llvm.org/releases/2.8/docs/ReleaseNotes.html Approved by: rpaulo (mentor)
* Upgrade our Clang in base to r114020, from upstream's release_28 branch.dim2010-09-2047-2011/+4608
| | | | Approved-by: rpaulo (mentor)
* Upgrade our Clang in base to r108428.ed2010-07-2042-5142/+6778
| | | | | | | | | 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-0979-0/+52265
in llvm/ and/or llvm/contrib/clang/ respectively. Approved by: ed (mentor) Approved by: core
OpenPOWER on IntegriCloud