similar to: sse, mmx support for hvm guests

Thanks for the help. I've a couple of questions though: How does LLVM deal with inline assembly? I'm trying to compile kernel and I get this error probably because LLVM is not able to handle inline assembly. I'm using LLVM-2.3 code snippet from "arch/x86_64/kernel/asm-offsets.c" .... #define DEFINE(sym, val) \ asm volatile("\n->" #sym " %0 "

Hi, I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit LLVM IR, which can be JITed at runtime $ make CROSS_COMPILE=llvm- CFLAGS="-O2 -emit-llvm" Error: not ELF make[2]: *** [scripts/mod/elfconfig.h] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 using

On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote: > Hi, > > I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all > possible? Yes, but it requires significant hacking, and the result for 2.6 is a mostly bitcode kernel with a few userspace shared libraries linked in as objcode (yes, the kernel builds .so files and includes them

On Sep 27, 2008, at 4:34 PM, Ashish Bijlani wrote: > Thanks for the help. I've a couple of questions though: > > How does LLVM deal with inline assembly? It's been implemented piece by piece on an as-needed basis. At this point most of the things people actually use should work. llvm-gcc has seen the Linux kernel, so most usages in there ought to work. The symptoms here

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

I'm working on changing the MMX implementation to use intrinsics in all cases, which should stop various optimization passes from creating MMX instructions that screw up the x87 stack. Right now the MMX instructions are split between X86InstrMMX.td and X86InstrSSE.td, presumably on the historical grounds that some of them weren't introduced until SSE or SSSE3, and require

On Jul 1, 2011, at 2:43 PM, Alistair Lynn wrote: > Hi Andrew- > >> fatal error: error in backend: SSE2 register return with SSE2 disabled > > Is this for 32-bit or 64-bit x86? 64-bit x86. > If it's the latter, the ABI demands > that the return value in this case is in xmm0 - SSE is required. > Well -no-sse -mno-mmx works for EFI as it is pre-boot firmware and

Thanks Kevin for the reply. I got the point now :) On 10 Apr 2015 00:18, "Smith, Kevin B" <kevin.b.smith at intel.com> wrote: > For x86_64 ABI, a minimum feature set of SSE2 is required. > > > > Kevin > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *suyog sarda > *Sent:* Thursday, April 09,

Your clang invocation below works for me, and generates target triple in the llvm IR of i386. And then in the specific options for the functions it generates the following: ; Function Attrs: nounwind define float @foo() #0 { entry: ret float 1.000000e+00 } attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"= "true"

Hi Andrew- > fatal error: error in backend: SSE2 register return with SSE2 disabled Is this for 32-bit or 64-bit x86? If it's the latter, the ABI demands that the return value in this case is in xmm0 - SSE is required. Alistair

On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while > llc -march=x86 -mattr=mmx

Hi Dale, I will not change the default. I would dislike to see any regressions due to this type of change. -- Mon Ping On Nov 20, 2008, at 10:12 AM, Dale Johannesen wrote: > > On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > >> Hi, >> >> When setting -mattr option on X86, I would like to treat MMX >> separately from SSE levels. This would allow a

Hi Andrew- > Well -no-sse -mno-mmx works for EFI as it is pre-boot firmware and does not have any floating point C code. We use -no-sse and -mno-mmx code to prevent optimized code gen using these registers for optimizations. Whether it's optimised or not doesn't particularly matter, the x86_64 ABI says that floating-point return values go into SSE registers, so that is where LLVM is

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>

Hi all, Recently some great work has been done to implement vector shifts as described in the language reference, and I'd like to contribute by attempting to match these operations on x86 to MMX and SSE instructions whenever possible. I'm experienced in writing MMX and SSE assembly but I'm unfamiliar with how LLVM performs instruction selection. So every bit of information to

Hello, I read in the announce of Xen 3.2.0 released that it has "preliminary support for a wider range of bootloaders in fully virtualised (HVM) guests, using full emulation of x86 ''real mode''" . I''d like to know what is the level of the emulation of x86 ''real mode''? I ask that because I tried to install OpenSuse 10.3 (I used the iso file

Thanks. I actually checked the IR code generated, it seems inline assembly is being handled correctly. The preprocessing is also being done correctly. Here is the asm-offsets.i file snippet.. ... builtin_offsetof(struct crypto_tfm,__crt_ctx))); asm volatile("\n->" : : ); asm volatile("\n->" "__NR_syscall_max" " %0 " "sizeof(syscalls) - 1"

Hi all, I've patched theora-mmx to build on x86_64. The patch against SVN is attached. Basically all I did was to copy lib/i386 to lib/x86_64 and tweak the assembler code a bit: * added to each file: typedef unsigned long int ogg_uint64_t * converted all asm inputs to 64-bit in: dsp_mmxext.c, fdct_mmx.c, recon_mmx.c * left all asm outputs at 32-bit * I didn't patch dsp_mmx.c, since all