similar to: [LLVMdev] CPU feature control for JIT

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

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

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 using certain target features? Thanks, Nicolas Capens -------------- next part

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

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

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

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

hi ��f�� but in the source code i find this comment. // ELF is a reasonably sane default and the only other X86 targets we // support are Darwin and Windows. Just use "not those". does this means that we can debug jit on windows? i am confused.help 2011/6/7 ��f�� <chenwj at iis.sinica.edu.tw>: > Hi, Tang > >> result is correct. But on windows, i failed. Why? I build

Hi, Tang > but in the source code i find this comment. > // ELF is a reasonably sane default and the only other X86 targets we > // support are Darwin and Windows. Just use "not those". I guess you found above comment in lib/Target/X86/X86Subtarget.h. But I think X86Subtarget.h is only related to the codegen, but NOT the debugging information. The comment means you can

Hi all, Is there any way to generate the binary code for a whole module at once? Currently I always get lazy compilation one function at a time. The reason I would like to generate the whole module at once is because I create some functions at run-time and then minimize the memory footprint by deallocating all LLVM objects. I've written my own JITMemoryManager to ensure that the binary

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hi all, I'm attempting to use LLVM for run-time code specialization, but I'm facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. So I was hoping that by first creating unspecialized LLVM

Hi Chris, Thanks for pointing me to that presentation! It helped me come up with a strategy that I believe might work: 1) Use CloneFunction() to make a copy of the original unspecialized (but optimized) function. 2) Specialize it using a custom function pass which identifies the specialization parameters and substitutes them with given run-time constants. 3) Run the function through a

Sure, you can turn off lazy compilation. Take a look at NoLazyCompilation in lli.cpp. Evan On Jul 7, 2008, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > Is there any way to generate the binary code for a whole module at > once? Currently I always get lazy compilation one function at a time. > > The reason I would like to generate the whole module at once is >