similar to: [LLVMdev] Changing target features from C++

On Jul 18, 2008, at 8:42 AM, Nicolas Capens wrote: > Hi all, > > How do I properly/conveniently change ISA features of the code to be > generated? For instance I have a Core 2 Duo with SSSE3 but I’d also > like to test whether everything would JIT compile correctly on > something with just SSE2 (a Pentium 4) or even older. In other > words, how do I prevent LLVM from

Hi Chris, I see. While hacking AutoDetectSubtargetFeatures() works for me for now, would it be useful to define an interface for X86Subtarget to change the features in a cleaner way? Would methods like disableSSEn()/enableSSEn() work or do you have another suggestion? I certainly want to avoid a situation where one module uses other settings than another module. Thanks, Nicolas

On Jul 20, 2008, at 2:59 AM, Nicolas Capens wrote: > Hi Chris, > > I see. While hacking AutoDetectSubtargetFeatures() works for me for > now, would it be useful to define an interface for X86Subtarget to > change the features in a cleaner way? Would methods like > disableSSEn()/enableSSEn() work or do you have another suggestion? I > certainly want to avoid a

Hi all, Is there a convenient way to control the instruction set extensions used for JIT compilation? In particular I'm looking at selecting the SSE level, for debugging and performance comparison purposes. There appear to be command-line options for Clang but I haven't figured out yet how to control them directly for JIT compilation. And obviously I don't want it to generate

On Oct 27, 2009, at 6:56 AM, Nicolas Capens wrote: > Hi all, > > Is there a convenient way to control the instruction set extensions > used for JIT compilation? > > In particular I’m looking at selecting the SSE level, for debugging > and performance comparison purposes. There appear to be command-line > options for Clang but I haven’t figured out yet how to control

Henning, I believe the code that is supposed to do this is in: lib/Target/X86/X86Subtarget.cpp in X86Subtarget::AutoDetectSubtargetFeatures() Is there a bug in that function? -Hal On Thu, 24 May 2012 23:56:48 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > On Thu, 24 May 2012, Pan, Wei wrote: > > > Very likely AVX is not enabled in your llc.

On Thu, 24 May 2012, Hal Finkel wrote: > Henning, > > I believe the code that is supposed to do this is in: > lib/Target/X86/X86Subtarget.cpp in > X86Subtarget::AutoDetectSubtargetFeatures() > Is there a bug in that function? I read there: // FIXME: AVX codegen support is not ready. //if ((ECX >> 28) & 1) { X86SSELevel = AVX; ToggleFeature(X86::FeatureAVX); }

Hi Adam, > OK. I know the reason you cannot reproduce it, before posting > the patch I've decided to check for AVX before checking AVX2, > just not to cpuid AVX2 when we don't have AVX1 anyway. I suspect it was also incompetence on my part. Given the differences I'm seeing now I can't believe there'd be *no* difference in my tests if I'd done them properly.

> That's far more worrying to me than not being able to detect Haswell. > I can't reproduce the problem here at the moment: both debug and > release builds give identical assembly for Host.cpp. OK. I know the reason you cannot reproduce it, before posting the patch I've decided to check for AVX before checking AVX2, just not to cpuid AVX2 when we don't have AVX1 anyway.

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

On Thu, 24 May 2012, Pan, Wei wrote: > Very likely AVX is not enabled in your llc. This feature was enabled > just recently (late of April). I forgot to mention that I am using recent LLVM-3.1 and in principle my llc knows about avx as I have shown in the second example. But avx does not seem to be used by default. On Thu, 24 May 2012, Henning Thielemann wrote: > $ llc -o - -mattr

Hi all, I'm trying to use LLVM to generate SIMD code at runtime (in particular Intel SSE). But I'm having a bit of trouble understanding how to create even the simplest function; adding two vectors of four single-precision floating-point elements. I can get it to add the elements one at a time but not using one vector instruction. All help much appreciated! Nicolas Capens

I wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void @_fun1(<8 x float>*, <8 x float>*) { _L1: %x = load <8 x float>* %0 %y = load <8 x float>* %1 %z = fadd <8 x float> %x, %y store

On Thu, May 8, 2008 8:24 am, Nicolas Capens wrote: > Hi all, > > > > I'm trying to use LLVM to generate SIMD code at runtime (in particular > Intel > SSE). But I'm having a bit of trouble understanding how to create even the > simplest function; adding two vectors of four single-precision > floating-point elements. I can get it to add the elements one at a time

Hello, Matthew. > My file size matches the patched file. I haven't figured out how to get 7-zip to give me checksum information on windows. Use md5sum utility. It can be successfully found via google. > I rashly copied all the *.o files from my mingw\lib directory to the llvm\lib directory. > This does enable the hello world binary to compile and to function correctly. Strange.

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Hi all, Please consider applying the attached patch. Currently on Windows x86-64 the processor features are not detected because the inline assembly (which Visual C++ deprecated for x64) does not have an alternative that uses intrinsics. Later tests for x86-64 then only enable SSE2, leaving any more recent instruction set unused. The patch uses the __cpuid intrinsic that compile under

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

Chris Lattner <clattner at apple.com> writes: > On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: > >> In X86Subtarget.h there is a method `getDataLayout' which selects the >> data layout depending on the platform, ignoring whatever the user setted >> with Module::setDataLayout. >> >> What's the rationale for this? > > Data layout is a

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to