similar to: [LLVMdev] Test Failures

Eli Friedman <eli.friedman at gmail.com> writes: > On Fri, Jul 8, 2011 at 9:13 AM, David Greene <dag at cray.com> wrote: >> I'm seeing a bunch of LLVM test failures that look like this: >> >> Exit Code: 1 >> Command Output (stderr): >> -- >> LLVM ERROR: SSE register return with SSE disabled >> >> Anyone else seeing this? > >

On Fri, Jul 8, 2011 at 9:13 AM, David Greene <dag at cray.com> wrote: > I'm seeing a bunch of LLVM test failures that look like this: > > Exit Code: 1 > Command Output (stderr): > -- > LLVM ERROR: SSE register return with SSE disabled > > Anyone else seeing this? That message means you're on 64-bit with SSE2 turned off. Probably fallout from recent

On Fri, Jul 8, 2011 at 11:02 AM, David A. Greene <greened at obbligato.org> wrote: > Eli Friedman <eli.friedman at gmail.com> writes: > >> On Fri, Jul 8, 2011 at 9:13 AM, David Greene <dag at cray.com> wrote: >>> I'm seeing a bunch of LLVM test failures that look like this: >>> >>> Exit Code: 1 >>> Command Output (stderr):

1. A program can use SSE instructions only if both CPU and OS support SSE. Currently libFLAC tests both CPU and OS for this support, but is it really necessary? Maybe CPU check is enough? Operating systems that don't support SSE (Win95, WinNT 4.0, Linux kernel 2.2 (iirc), ...) are really outdated now. Removing OS check will greatly simplify src/libFLAC/cpu.c. 2. "configure" build

Dave Yeo wrote: >>> >on other OSes: >>> > --enable-sse: >>> > add -msse2 to the compiler switches >>> > test SSE OS support (why?) >>> >It's a bit contradictory: why test whether *BSD etc support SSE or not >>> >but at the same time allow compiler to use SSE/SSE2 unconditionally? >> Yes,

First off, this code is horrible to read and work on. The recent commits are the first of what I hope is a massive clean up of this code. lvqcl wrote: > So if I understand things correctly, the current meaning of --(en|dis)able-sse is: > > on Linux: > --enable-sse: > add -msse2 to the compiler switches > do not test SSE OS support (assume that SSE is

Thomas Zander wrote: > In any case, the disable-SSE matter is still important. People are > still using flac on x86 machines without SSE, for instance AMD Geode > CPUs seem to live forever. libFLAC detects CPU SSE support in runtime, so --disable-sse is necessary for cuch CPUs only because it disables -msse2 switch. Maybe it makes sense to add new switch, --no-force-sse2 or

On Thu, Dec 25, 2008 at 1:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 25, 2008 at 1:28 AM, Claudio Basile <cbasile at tempo-da.com> wrote: >> Hi all, >> >> is there any way to compare two 128bit values? >> I have tried 3 different approaches and they all fail with an internal >> assertion. >> I'm running llvm 2.4 on

my server has intel q9550 cpu (which supports intel-vt) and intel s3200 motherboard. BIOS has enabled intel virtualisation. centos 5.4, 64bit [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.18-164.el5xen #1 SMP Thu Sep 3 04:03:03 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# grep vmx /proc/cpuinfo flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36

I've run into an issue specifying intrinsics for AVX. Right now one can use GCCBuiltin to get automatic CBE (and other) support for emitting intrinsics as gcc builtins. It looks like this: def int_x86_sse3_hadd_pd : GCCBuiltin<"__builtin_ia32_haddpd">, Intrinsic<[llvm_v2f64_ty], [llvm_v2f64_ty, llvm_v2f64_ty], [IntrNoMem]>; AVX

That’s useful info, thanks. I think it will be useful for me to understand the connection, why this type of pointer is being emitted now. Do you have any suggestions where i can look to find the platform specific code that is making function pointers go into addrspace? Carl p.s. I am also working on passing the avr target flag to swift, but swift itself had (has?) limitations that make it

I've been working on adding AVX to LLVM and have run across a number of questions. Here's the first one. In some ways AVX is "just another" SSE level. Having AVX implies you have SSE1-SSE4.2. However AVX is very different from SSE and there are a number of sub-features which may or may not be available on various implementations. So right now I've done this: def

So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:

Cool. That explains a lot! Sorry if this is a total n00b question, but… how does the datalayout string get overridden? in llvm/lib/Target/AVR/AVRTargetMachine.cpp I can see the code that determines the default datalayout for AVR… static const char *AVRDataLayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8”; However in the LLVM iR below, the target datalayout was present and

On Thu, 20 Apr 2006, Simon Burton wrote: >>> From what I remember, this is a bug in debian libc: >> some floating point flags are set incorrectly causing SIGFPE. >> Can't find the bug report ATM. > > Oh, it just showed up on numpy-discussion: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > > """ > #include <fenv.h> > void

Eric Christopher <echristo at apple.com> writes: > On Nov 8, 2011, at 7:20 PM, David A. Greene wrote: > > I couldn't figure out how to run the test-suite. Are there up-to-date > instructions somewhere? llvm-gcc doesn't exist anymore... > > Easiest is to check out the test-suite branch into projects and then after you configure and build from the top

Eli Friedman <eli.friedman at gmail.com> writes: > int_x86_avx_vhadd_pd_xmm doesn't exist on trunk. Why does it exist on > your branch if the semantics are exactly equivalent to > int_x86_sse3_hadd_pd? The register allocator can handle converting to > three-address form if the target provides the appropriate hooks. Because in some cases users may want to explicitly use

On 03/14/16 03:51 PM, lvqcl wrote: > With --disable-sse, FLAC__SSE_OS is undefined and FLAC__cpu_info() uses > sigemptyset/sigaction to determine OS SSE support. That's not quite right as I have to build binaries with --disable-sse (I build and distribute both with and without) so that some users on PII's don't get a sigill, even though the OS supports SSE. So it seems to

> On Tue, May 15, 2007 at 01:23:32AM -0700, Tanya M. Lattner wrote: >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> >> It would also be helpful for someone to compile/test with objdir != srcdir. > > This is on FreeBSD 6.2-RELEASE, on i386. > Both llvm and

Hi, I’ve come back and updated my llvm toolset with modern code (my branch was about 1-2 years old) and now the llvm IR files produced by my front end no longer compile with llc. Here is a sample of llvm ir produced by my front end (it’s a standard version 3.1 build of swift from the swift.org open source website). ; ModuleID = 'main.ll' source_filename = "main.ll" target