search for: autodetectsubtargetfeatur

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...

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

...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? > The JIT defaults to using whatever it can. You can hack X86Subtarget::AutoDetectSubtargetFeatures() to disable specific features. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080718/0f2bffa2/attachment.html>

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. This feature was > > enabled just...

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 situation where one module uses...

...E level lower, not higher). Is this already supported, > or would anyone else be interested in that and/or be able to suggest > how best to add this feature? > The JIT autosenses the current CPU and forces the features it detects, you can hack this by (e.g.) changing X86Subtarget::AutoDetectSubtargetFeatures. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091028/546e6d33/attachment.html>

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); } It looks like the check for AVX is disabled intentionally. But if the AVX codegen is now usable, one...

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

...;ve only tested it with my own experimental project on Windows x64 but I see no potential issues for other platforms. A potential additional improvement would be to cause a compiler error when the GetCpuIDAndInfo does not compile to the intended code, and to remove the test that follows right after AutoDetectSubtargetFeatures() has been called. Kind regards, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090424/df096752/attachment.html> -------------- next part -------------- A non-text attachment was scrubb...

...:42 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > 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); } > > > It looks like the check for AVX is disabled intenti...

...case 38: // 45 nm Atom Lincroft case 39: // 32 nm Atom Medfield diff --git a/lib/Target/X86/X86Subtarget.cpp b/lib/Target/X86/X86Subtarget.cpp index fa04c38..d221316 100644 --- a/lib/Target/X86/X86Subtarget.cpp +++ b/lib/Target/X86/X86Subtarget.cpp @@ -285,7 +285,8 @@ void X86Subtarget::AutoDetectSubtargetFeatures() { (Family == 6 && Model == 0x2F) || // Westmere: Westmere-EX (Family == 6 && Model == 0x2A) || // SandyBridge (Family == 6 && Model == 0x2D) || // SandyBridge: SandyBridge-E* - (Family == 6 && Model == 0x3A))) {// IvyBridge +...

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 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.

...case 38: // 45 nm Atom Lincroft case 39: // 32 nm Atom Medfield diff --git a/lib/Target/X86/X86Subtarget.cpp b/lib/Target/X86/X86Subtarget.cpp index fa04c38..597fccb 100644 --- a/lib/Target/X86/X86Subtarget.cpp +++ b/lib/Target/X86/X86Subtarget.cpp @@ -285,7 +285,12 @@ void X86Subtarget::AutoDetectSubtargetFeatures() { (Family == 6 && Model == 0x2F) || // Westmere: Westmere-EX (Family == 6 && Model == 0x2A) || // SandyBridge (Family == 6 && Model == 0x2D) || // SandyBridge: SandyBridge-E* - (Family == 6 && Model == 0x3A))) {// IvyBridge +...

> 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

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