similar to: [LLVMdev] Haswell New Instructions

The important thing IMO, is to not represent the gather operation as an instruction which takes a vector of pointers, because that's too restrictive for architectures with 64bits pointers. What one most frequently wants to do in those architectures is to specify a 64bit scalar base pointer with a vector of 32bit offsets. This fits what the VGATHERxxx described in the spec provides, and this

On Jun 13, 2011, at 4:41 AM, Nicolas Capens wrote: > > So I was wondering whether in LLVM a gather operation is best represented with a 'load' instruction taking vector operands, or whether it's better to define it as a separate 'gather' instruction. What would be the pros and cons of each approach, and what do you think should be the long-term goals for the LLVM

On Jun 13, 2011, at 6:48 AM, Dan Gohman wrote: > On Jun 13, 2011, at 4:41 AM, Nicolas Capens wrote: >> >> So I was wondering whether in LLVM a gather operation is best represented with a 'load' instruction taking vector operands, or whether it's better to define it as a separate 'gather' instruction. What would be the pros and cons of each approach, and what do

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.

Hello, This is my first patch on this list, however I've already submitted several trough bug tracking system. Since it probably needs some review and it's not a bug I am submitting it here. The main intent of this patch is to detect "core-avx2" platform on Haswell i7 CPUs when running -march=native. Currently it detects it as generic x86_64. lib/Support/Host.cpp: * Haswell is

> 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

Hi Adam, > * I have marked HasAVX2 as "volatile", since otherwise it gets > magically zeroed (by optimizer?) when compiling clang with latest > clang build from trunk 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. I don't

On Tue, Aug 19, 2014 at 5:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s > really close, but not 100% the same. What is the difference? and why? It seems really confusing to have this divergence, or to be unable to replicate the *exact* behavior of this (very weird, and IMO *bad* triple) with the standard

> I promise I'll do the review of your code after that. Tim, I don’t want to push too much. But since there’s 3.4 release on the horizon, maybe you could find a moment review this patch. Especially Haswell is all there since few months. Cheers, -- Adam --- lib/Support/Host.cpp | 8 ++++++++ lib/Target/X86/X86Subtarget.cpp | 3 ++- 2 files changed, 10 insertions(+), 1

Sounds good, I'll give it a try sooner or later. I've never messed with triples, so is there anything I need to be aware of so I don't break any code on other platforms? In particular, I want llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware triple, so what do I need to do to ensure that I don't break anyone else who is running one of these systems and

Hi, I'm running libvert on a Debian 7 system. I have upgraded libvert and qemu from source (v1.06 and 1.5.0 respectively) and the problem persists. The guest OS is also a Debian 7 system running a non-SMP kernel. The error message from virt-manager is Error starting domain: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm,

I have a group of students working with me on some LLVM projects related to our Parabix research. One interesting issue that has come up for us is code generation support for the Haswell new instructions pext and pdep. These instructions shuffle bits within a 64-bit word, either gathering all selected bits to the beginning (pext) or scattering some initial bits throughout (pdep). A natural

I have one of those new little NUC's and installed Centos 7.1 on it. lspci shows 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 09) 00:14.0 USB controller: Intel Corporation 8 Series

>> + bool HasAVX2 = HasAVX && !GetX86CpuIDAndInfo(0x7, &EAX, &EBX, &ECX, &EDX) && >> + (EBX & 0x20); > > I don't think this guarantees %ecx is 0, does it? Wasn't that the > entire reason the original code went wrong? I don’t remember really, but presuming the conclusions of the discussion, seems it is fixed now. It

Here we go, updated patch following your advice checking max leaf and porting cpuidex for subleaf (ECX) 0. NOTE: I’ve set Haswell to be not only 60, but also 63, 69 & 70 model, following changes in Linux kernel & Xen. Also set 62 as Ivy Bridge EP aka E5 v3 (which I has in my workstation). Cheers, -- Adam Detects x86 family 6 model 60, 63, 69, 70 CPU that has AVX2 CPUID leaf 7 subleaf

Hi, I'm running libvert on a Debian 7 system. I have upgraded libvert and qemu from source (v1.06 and 1.5.0 respectively) and the problem persists. The guest OS is also a Debian 7 system running a non-SMP kernel. The error message from virt-manager is Error starting domain: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm,

hello , thanks for comments . I tried now with force options for CPU flag which were not supported . Now the command with non fully supported CPU model gets executed , But i am surprised to see that still Guest cpu model is not changed and still same as host cpu model(SAndy Bridge) Why don't i see the model as HAswell now , could you please comment. Command used : virt-install

Sorry to blow up everyone's email on this but I tried something new and found a different problem. I uninstalled all the debian package (libvirt, kvm, qemu, virt-manager, etc.) and then remade all the packages and installed them. Haswell again shows up in virt-manager, but now any CPU I choose including kvm64 and qemu64 give the same error: root@mal:~# virsh create

> I don’t remember really, but presuming the conclusions of the discussion, seems it is fixed now. It was something about registers when using inline assembly. Anyway this works just fine on all my Haswell machines. I think that's more coincidence than anything else (something perturbed in your host compiler's backend). If you look at lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp