similar to: CentOS 6 / Intel CPU support

> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>: > >> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: >> >> https://access.redhat.com/support/policy/intel >> >> shows mainly Xeon CPUs. What about >> >> Intel Core i7-6700 Quad-Core Skylake >> >> has the current EL6

> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: > > https://access.redhat.com/support/policy/intel > > shows mainly Xeon CPUs. What about > > Intel Core i7-6700 Quad-Core Skylake > > has the current EL6 variant support for it? > > Any experience? Feedback would be greatly appreciated. I found this

On 05/11/2017 12:45 PM, Leon Fauster wrote: >> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>: >> >>> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: >>> >>> https://access.redhat.com/support/policy/intel >>> >>> shows mainly Xeon CPUs. What about >>> >>>

> Here's mine. Interesting differences: If you disable Intel Speedstep in the BIOS it should lock the CPU to its fastest speed, but you lose power saving during idle. On Thu, May 11, 2017 at 3:48 PM, ken <gebser at mousecar.com> wrote: > On 05/11/2017 12:45 PM, Leon Fauster wrote: > >> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>:

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

It is my actual target architecture ________________________________ From: Doerfert, Johannes <jdoerfert at anl.gov> Sent: Saturday, March 23, 2019 1:30 PM To: J S Cc: via llvm-dev Subject: Re: [llvm-dev] Generating object files more efficiently I copied "-march=XYZ" from your original email, you have to replace it with your actual target architecture or simply drop it.

Johannes, I tried the last one and it gave me this: error: unknown target CPU 'XYZ' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake,

There has been some progress, but still no joy. Definitely not intended for inclusion at this point. Tim, Wei, I added a Xen command line toggle to disable IOMMU and P2M table sharing. Tim, I verified that changes to p2m-pt.c don''t break shadow mode (64bit hypervisor and Win 7 guest). Hongkaixing, I incorporated your suggestion in patch 2, so I should add your Signed-off-by eventually.

-march for clang and -march for llc do different things unfortunately. -march for clang at least on x86 is the same as -mcpu in llc. Which is an artifact of gcc compatibility. ~Craig On Sat, Mar 23, 2019 at 1:40 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Oh, my bad. > > > Idk why llc seems to know that architecture but clang does not. > >

On 11/5/2017 10:45 PM, Sorin Srbu wrote: > What would you consider be a tested and proven working, newish chipset? its really the CPU now that matters, rather than the 'chipset', as most all the base IO devices are in the CPU (ethernet, sata, video). I think Kaby Lake support is still a sketchy, thats Core gen 7. (i-7xxx). I'm not sure what the state of Skylake is (gen 6)

From: Borislav Petkov <bp at suse.de> Use boot_cpu_has() instead. Signed-off-by: Borislav Petkov <bp at suse.de> Cc: virtualization at lists.linux-foundation.org Cc: sparmaintainer at unisys.com --- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 -

From: Borislav Petkov <bp at suse.de> Use boot_cpu_has() instead. Signed-off-by: Borislav Petkov <bp at suse.de> Cc: virtualization at lists.linux-foundation.org Cc: sparmaintainer at unisys.com --- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 -

Hello Matthew, On Thu, 27 Jul 2017 15:59:35 -0400 Matthew Miller <mattdm at mattdm.org> wrote: > On Thu, Jul 27, 2017 at 08:38:14PM +0200, wwp wrote: > > Say, instead of stable, something not rawhide. But I'll examine all > > options that do work, so let's forget about "stable". > > In that case ? and I freely admit I have some bias here ? I

Currently I compile my C code in 2 steps in order to generate .o files clang -emit-llvm -c foo.c -o foo.bc llc -march=XYZ foo.bc -filetype=obj Is there a way to generate either .o or .elf files in just 1 command? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190323/da9b3c18/attachment.html>

Hello, Anybody know the reason RedHat decided not to support the VIA Eden Processor? cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA Eden Processor 500MHz I am testing, (using ayplus kernel) and get the following during bootup: Linux version 2.6.32-71.24.1.el6.centos.ayplus.1.i686 (build at 6beta32) (gcc versi

On 11/13/2017 05:49 PM, Eric Christopher wrote: > > > On Mon, Nov 13, 2017 at 2:15 PM Craig Topper via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Nov 11, 2017 at 8:52 PM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On

I haven't looked into actually implementing revectorization, so we may just want to ignore that possibility for now. But I imagined that revectorization could hit the same problem that we're trying to avoid here: if the cost models say that wider vectors are legal and cheaper, but the reality is that perf will suffer when using those wider vectors, then we want to avoid using the wider

On Sat, Nov 11, 2017 at 8:52 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/11/2017 09:52 PM, UE US via llvm-dev wrote: > > If skylake is that bad at AVX2 > > > I don't think this says anything negative about AVX2, but AVX-512. > > it belongs in -mcpu / -march IMO. > > > No. We'd still want to enable the architectural

If I'm understanding correctly, you're saying that vgather* is slow on all of Excavator, Haswell, Broadwell, and Skylake (client). Therefore, we will not generate it for any of those machines. Even if that's true, we should not define "gatherIsSlow()" as "hasAVX2() && !hasAVX512()". It could break for some hypothetical future processor that manages to