search for: togglefeatur

...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 could enable the AVX check, right?

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.

...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 could enable the AVX check, > right? -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...gnized feature for this target (ignoring feature) '-pclmul' is not a recognized feature for this target (ignoring feature) ..... The processor I used is generic, def : Processor<"generic", NoItineraries, []>; I used lldb to trace the code and didn't find it ran into ::ToggleFeature() or SubtargetFeatures::getFeatureBits() from where I see the warning string comes. Any guide or suggestion is appreciated! Thanks in advanced! -ye -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130517/...

...(Family == 6 && Model == 0x2D) || // SandyBridge: SandyBridge-E* - (Family == 6 && Model == 0x3A))) {// IvyBridge + (Family == 6 && Model == 0x3A) || // IvyBridge + (Family == 6 && Model == 0x3C))) {// Haswell IsUAMemFast = true; ToggleFeature(X86::FeatureFastUAMem); } -- 1.8.3.4 (Apple Git-47)

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.

...0x3E) || // IvyBridge EP + (Family == 6 && Model == 0x3C) || // Haswell + (Family == 6 && Model == 0x3F) || // ... + (Family == 6 && Model == 0x45) || // ... + (Family == 6 && Model == 0x46))) { // ... IsUAMemFast = true; ToggleFeature(X86::FeatureFastUAMem); } -- 1.8.3.4 (Apple Git-47)

> 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