Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On 13 Aug 2013, at 21:57, Jilles Tjoelker jil...@stack.nl wrote: Given that JIT is for performance and larger addresses increase code size and register pressure, the mmap() flag is probably useful. Alternatively, all the JITted code could be placed in one block and use relative addressing. This would be a good thing to have in for 10.0, as the LLVM 3.4 JIT will require it unless someone wants to contribute support for the large code model... David ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Wednesday, August 14, 2013 4:23:11 am David Chisnall wrote: On 13 Aug 2013, at 21:57, Jilles Tjoelker jil...@stack.nl wrote: Given that JIT is for performance and larger addresses increase code size and register pressure, the mmap() flag is probably useful. Alternatively, all the JITted code could be placed in one block and use relative addressing. This would be a good thing to have in for 10.0, as the LLVM 3.4 JIT will require it unless someone wants to contribute support for the large code model... So you just need a flag to cap the virtual address at 2GB? Do you think we need an arbitrary address flag for this, or is a hardcoded 2GB flag ok? Linux has a MAP_32BIT that does what you want I think. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On 14 Aug 2013, at 13:21, John Baldwin j...@freebsd.org wrote: On Wednesday, August 14, 2013 4:23:11 am David Chisnall wrote: On 13 Aug 2013, at 21:57, Jilles Tjoelker jil...@stack.nl wrote: Given that JIT is for performance and larger addresses increase code size and register pressure, the mmap() flag is probably useful. Alternatively, all the JITted code could be placed in one block and use relative addressing. This would be a good thing to have in for 10.0, as the LLVM 3.4 JIT will require it unless someone wants to contribute support for the large code model... So you just need a flag to cap the virtual address at 2GB? Do you think we need an arbitrary address flag for this, or is a hardcoded 2GB flag ok? Linux has a MAP_32BIT that does what you want I think. Yes, MAP_32BIT is used on Linux to solve this. David ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Thu, Aug 08, 2013 at 09:37:02AM +0100, David Chisnall wrote: On 7 Aug 2013, at 21:56, Jilles Tjoelker jil...@stack.nl wrote: The code_model stuff is not for x32 support but for PIC/PIE code where code+data exceed 2GB so relative addressing cannot always be used. The ABI then prescribes that %r15 be loaded with the GOT pointer when invoking a large model (code2GB) PLT entry; otherwise (medium model or no PLT entry used), much like i386, any register can be used for the GOT pointer. Does our rtld provide support for this? We recently encountered a problem with the new LLVM JIT because FreeBSD's mmap() does not provide a way of requesting memory that is below the 2GB line and so we can't use the small code model. Our rtld does not seem to support the large PLT layout, but the regular layout may (should) be used if the PLT can reach the GOT via relative (=2GB) addressing. This should be the case unless very many symbols are used. I think it is more likely to encounter problems with ld. Support for the larger models may have been added later. Given that JIT is for performance and larger addresses increase code size and register pressure, the mmap() flag is probably useful. Alternatively, all the JITted code could be placed in one block and use relative addressing. -- Jilles Tjoelker ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Tue, Jul 30, 2013 at 04:16:58PM +0200, Dimitry Andric wrote: Upstream gcc checks this with: #if defined(__i386__) defined(__PIC__) ... #elif defined(__x86_64__) (defined(__code_model_medium__) || defined(__code_model_large__)) defined(__PIC__) ... and it exchanges ebx or rbx with %k1 or %q1, respectively, instead of push/pop. That might be a little more efficient. I guess the defined(__PIC__) should be enough for us, in most cases. The code_model stuff is for x32 support, which we do not have yet. The code_model stuff is not for x32 support but for PIC/PIE code where code+data exceed 2GB so relative addressing cannot always be used. The ABI then prescribes that %r15 be loaded with the GOT pointer when invoking a large model (code2GB) PLT entry; otherwise (medium model or no PLT entry used), much like i386, any register can be used for the GOT pointer. In x32, relative addressing can always be used and there is no need for a PIC register. I don't really understand why special tricks are needed for %ebx/%rbx. With the b constraint or %ebx clobber, adequate information is provided to the compiler that %ebx/%rbx will have to be saved somewhere around the asm. And in fact this appears to work fine with clang; only gcc (4.2.1 and 4.4.3; I have not tested newer versions) needs special trickery to access %ebx. -- Jilles Tjoelker ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Jul 30, 2013, at 15:33, Jan Beich jbe...@tormail.org wrote: Dimitry Andric d...@freebsd.org writes: Author: dim Date: Tue Jul 30 12:33:21 2013 New Revision: 253802 URL: http://svnweb.freebsd.org/changeset/base/253802 Log: Pull in r186696 from upstream clang trunk: This patch implements __get_cpuid_max() as an inline and __cpuid() and __cpuid_count() as macros to be compatible with GCC's cpuid.h. [...] +#define bit_SSE41 0x0008 +#define bit_SSE42 0x0010 GCC's spelling is different $ fgrep -r bit_SSE4 /usr/local/lib/gcc48/**/ /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4_1(1 19) /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4_2(1 20) /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4a (1 6) Even Clang's own from -msse* $ clang -dM -E -march=btver2 -/dev/null | fgrep -i sse4 #define __SSE4A__ 1 #define __SSE4_1__ 1 #define __SSE4_2__ 1 Hm, that's a good one. John, is it OK to adapt those to match gcc's definitions? We should also submit it upstream then. -Dimitry ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Tue, Jul 30, 2013 at 5:33 AM, Dimitry Andric d...@freebsd.org wrote: Author: dim Date: Tue Jul 30 12:33:21 2013 New Revision: 253802 URL: http://svnweb.freebsd.org/changeset/base/253802 Log: Pull in r186696 from upstream clang trunk: This patch implements __get_cpuid_max() as an inline and __cpuid() and __cpuid_count() as macros to be compatible with GCC's cpuid.h. It also adds bit_foo constants for the various feature bits as described in version 039 (May 2011) of Intel's SDM Volume 2 in the description of the CPUID instruction. The list of bit_foo constants is a bit exhaustive (GCC doesn't do near this many). More bits could be added from a newer version of SDM if desired. Patch by John Baldwin! This should fix several ports which depend on this functionality being available. MFC after:1 week Modified: head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Modified: head/contrib/llvm/tools/clang/lib/Headers/cpuid.h == --- head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Tue Jul 30 12:17:45 2013(r253801) +++ head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Tue Jul 30 12:33:21 2013(r253802) +/* PIC on i386 uses %ebx, so preserve it. */ +#if __i386__ +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ +__asm( pushl %%ebx\n \ +cpuid\n \ +mov%%ebx,%1\n \ +popl %%ebx \ +: =a(__eax), =r (__ebx), =c(__ecx), =d(__edx) \ +: 0(__level)) + +#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ +__asm( pushl %%ebx\n \ +cpuid\n \ +mov%%ebx,%1\n \ +popl %%ebx \ +: =a(__eax), =r (__ebx), =c(__ecx), =d(__edx) \ +: 0(__level), 2(__count)) +#else +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ +__asm(cpuid : =a(__eax), =b (__ebx), =c(__ecx), =d(__edx) \ + : 0(__level)) + +#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ +__asm(cpuid : =a(__eax), =b (__ebx), =c(__ecx), =d(__edx) \ + : 0(__level), 2(__count)) +#endif PIC mode on amd64 also uses %ebx. The difference is that FreeBSD makefiles set -fPIC for i386 kernel compile but not amd64. Locally we use -fPIC for amd64 (it was added 6 years ago to our environment because it gave better kernel debugging). Anyways, is there some way to detect PIC mode and use that to decide whether to use %ebx for the cpuid instruction, rather than using i386? Thanks, matthew ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Jul 30, 2013, at 16:09, Matthew Fleming m...@freebsd.org wrote: On Tue, Jul 30, 2013 at 5:33 AM, Dimitry Andric d...@freebsd.org wrote: Author: dim Date: Tue Jul 30 12:33:21 2013 New Revision: 253802 URL: http://svnweb.freebsd.org/changeset/base/253802 Log: Pull in r186696 from upstream clang trunk: This patch implements __get_cpuid_max() as an inline and __cpuid() and __cpuid_count() as macros to be compatible with GCC's cpuid.h. It also adds bit_foo constants for the various feature bits as described in version 039 (May 2011) of Intel's SDM Volume 2 in the description of the CPUID instruction. The list of bit_foo constants is a bit exhaustive (GCC doesn't do near this many). More bits could be added from a newer version of SDM if desired. ... +/* PIC on i386 uses %ebx, so preserve it. */ +#if __i386__ +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ +__asm( pushl %%ebx\n \ +cpuid\n \ +mov%%ebx,%1\n \ +popl %%ebx \ ... PIC mode on amd64 also uses %ebx. The difference is that FreeBSD makefiles set -fPIC for i386 kernel compile but not amd64. Locally we use -fPIC for amd64 (it was added 6 years ago to our environment because it gave better kernel debugging). Anyways, is there some way to detect PIC mode and use that to decide whether to use %ebx for the cpuid instruction, rather than using i386? Upstream gcc checks this with: #if defined(__i386__) defined(__PIC__) ... #elif defined(__x86_64__) (defined(__code_model_medium__) || defined(__code_model_large__)) defined(__PIC__) ... and it exchanges ebx or rbx with %k1 or %q1, respectively, instead of push/pop. That might be a little more efficient. I guess the defined(__PIC__) should be enough for us, in most cases. The code_model stuff is for x32 support, which we do not have yet. -Dimitry ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Tuesday, July 30, 2013 9:33:51 am Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: Author: dim Date: Tue Jul 30 12:33:21 2013 New Revision: 253802 URL: http://svnweb.freebsd.org/changeset/base/253802 Log: Pull in r186696 from upstream clang trunk: This patch implements __get_cpuid_max() as an inline and __cpuid() and __cpuid_count() as macros to be compatible with GCC's cpuid.h. [...] +#define bit_SSE41 0x0008 +#define bit_SSE42 0x0010 GCC's spelling is different $ fgrep -r bit_SSE4 /usr/local/lib/gcc48/**/ /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4_1(1 19) /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4_2(1 20) /usr/local/lib/gcc48/**/cpuid.h:#define bit_SSE4a (1 6) Note that this was a clean-room implementation, so I based this on the names in the Intel SDM. I was actually hoping for discussion on the clang lists perhaps along the lines of not supplying these constants at all, or only a subset, etc. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers
On Tuesday, July 30, 2013 10:09:35 am Matthew Fleming wrote: On Tue, Jul 30, 2013 at 5:33 AM, Dimitry Andric d...@freebsd.org wrote: Author: dim Date: Tue Jul 30 12:33:21 2013 New Revision: 253802 URL: http://svnweb.freebsd.org/changeset/base/253802 Log: Pull in r186696 from upstream clang trunk: This patch implements __get_cpuid_max() as an inline and __cpuid() and __cpuid_count() as macros to be compatible with GCC's cpuid.h. It also adds bit_foo constants for the various feature bits as described in version 039 (May 2011) of Intel's SDM Volume 2 in the description of the CPUID instruction. The list of bit_foo constants is a bit exhaustive (GCC doesn't do near this many). More bits could be added from a newer version of SDM if desired. Patch by John Baldwin! This should fix several ports which depend on this functionality being available. MFC after:1 week Modified: head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Modified: head/contrib/llvm/tools/clang/lib/Headers/cpuid.h == --- head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Tue Jul 30 12:17:45 2013(r253801) +++ head/contrib/llvm/tools/clang/lib/Headers/cpuid.h Tue Jul 30 12:33:21 2013(r253802) +/* PIC on i386 uses %ebx, so preserve it. */ +#if __i386__ +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ +__asm( pushl %%ebx\n \ +cpuid\n \ +mov%%ebx,%1\n \ +popl %%ebx \ +: =a(__eax), =r (__ebx), =c(__ecx), =d(__edx) \ +: 0(__level)) + +#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ +__asm( pushl %%ebx\n \ +cpuid\n \ +mov%%ebx,%1\n \ +popl %%ebx \ +: =a(__eax), =r (__ebx), =c(__ecx), =d(__edx) \ +: 0(__level), 2(__count)) +#else +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ +__asm(cpuid : =a(__eax), =b (__ebx), =c(__ecx), =d(__edx) \ + : 0(__level)) + +#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ +__asm(cpuid : =a(__eax), =b (__ebx), =c(__ecx), =d(__edx) \ + : 0(__level), 2(__count)) +#endif PIC mode on amd64 also uses %ebx. The difference is that FreeBSD makefiles set -fPIC for i386 kernel compile but not amd64. Locally we use -fPIC for amd64 (it was added 6 years ago to our environment because it gave better kernel debugging). Note that this is used in userland and the kernel. Anyways, is there some way to detect PIC mode and use that to decide whether to use %ebx for the cpuid instruction, rather than using i386? Does clang supply a reliable #define to indicate that PIC is in use? If not, then this should use the PIC path always to be safe. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
