search for: x87

Hello there, I recently started working on the LLVM backend for a target that doesn't support x87 instructions. Currently, I am in the process of completely disabling some x87 instructions such as fcomi, fcompi,... for a specific sub-target. I also do not have SSE enabled for my sub-target, and llvm resorts to fcomi* instructions for FP compare instructions. Is there a way to bypass the automa...

Hi Sriram, I'm not sure if I understand your question correctly: Do you need to generate code that contains no x87 floating-point instructions altogether, but uses calls into a soft-float library instead? That behaviour can be enabled using the "-soft-float" flag, as far as I know. Or is it only about the fcomi* instructions, which are not supported by pre-Pentium Pro chips? Then I have good news: I...

Hi All I am a greenhand for LLVM. I find the LLVM generate SSE instrctions for floating pointing computation, is there some method or options to let it generate x87 instructions? Thanks Simon -- >From : Simon.Zhou at PPI, Fudan University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090916/4717f6df/attachment.html>

Thanks Chris, your response has been very helpful so far. I will try your solution, as opposed to the one that I have right now. (Disabling all the x87 instructions altogether). Yours, Ram -----Original Message----- From: Christoph Erhardt [mailto:christoph at sicherha.de] Sent: Thursday, April 05, 2012 7:08 PM To: Murali, Sriram Subject: Re: [LLVMdev] Disabling x87 instructions for a sub-target Hi Ram, of course I can share the patch with yo...

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 support for that feature to work. I'm thinking it would be cleaner to keep them all...

Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT routine _ftol2 for floating-point to unsigned conversions, but this function has a nonstandard calling convention LLVM doesn't understand. It takes its input operand on the x87 stack as ST0, which it pops off of the stack before returning. The return value is given in EDX:EAX. In effect, I need to call it like this: %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags}" (double %x) nounwind but with the added consideration that the i...

...ine assembly instruction from a code generator pass? How can I do that with the proper diagnostic format and source location? Right now we only get: clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c fatal error: error in backend: Inline asm output regs must be last on the x87 stack But gcc-4-2 can: $ gcc-4.2 -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c: In function ‘foo’: /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c:5: error: output regs must be grouped at top o...

...lare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i32, i1) #5 attributes #0 = { noreturn "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+fxsr,+mmx,+x87,+sse,+sse2,+sse3" } attributes #1 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+fxsr,+mmx,+x87,+sse,+sse2,+sse3" } attributes #2 = { noinline nounwi...

...e MSVCRT `_ftol2` function implements floating-point-to-unsigned conversion for i386 targets, and LLVM 3.0 calls it with the cdecl calling convention for `fptoui to i64` when targeting i386-pc-win32. However, it has its own calling convention: The input value is taken from ST0 and popped off of the x87 stack, and the return value is given in EDX:EAX. EAX, EDX, and ST0 are clobbered (the latter by popping the stack). The function creates a stack frame. It messes with the x87 control word internally, but the original control word is restored before returning. -Joe

...e generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal error: error in backend: Inline asm output regs must be last on the x87 stack > > But gcc-4-2 can: > > $ gcc-4.2 -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c: In function ‘foo’: > /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c:5: error: output...

I recently diagnosed a bug in someone else's software, which turned out to be due to incorrect MMX intrinsics usage: if you use any of the x86 intrinsics that accept or return __m64 values, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that the compiler forced users to deal with this when using intrinsics. This is a real nasty footgun -- if you get this wrong, your program doesn't crash -- no, that would be...

On Jan 18, 2012, at 8:56 PM, Joe Groff wrote: > 2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: >> This should work: >> %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind > > Forgive me for being slow, but what would be the best way to implement > the equivalent of that inline asm as a custom

...loads in floating-point immediates are not preserved through compilation on 32-bit builds. I took a look and the corruption takes place when the immediates are converted from APFloats to be stored as native doubles in MCOperand. I assume this bug only appears in 32-bit builds because they are using x87 doubles that happen to not preserve all possible NaN payloads. There are two things we could do here: Change MCOperand to not store floating point immediates as native doubles, or explicitly accept that NaN payloads in immediates will not necessarily be preserved through compilation. The ability...

On Jun 16, 2007, at 12:35 AM, Duncan Sands wrote: >> Result compiled with llvm-g++ 2.0: >> tan float: -2.18504 >> tan double: 0.309336 > > This may be due to bug 1505. It fails on x86 using x87 floating point, with the inliner not run, because of 1505, yes. Gonsolo, is that your situation? (What happens is, there is a wrapper in the header file for std::tan (float), like this: inline float tan(float __x) { return __builtin_tanf(__x); } This wrapper is miscompiled due to 150...

...@llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i32, i1) #5 > > attributes #0 = { noreturn "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+fxsr,+mmx,+x87,+sse,+sse2,+sse3" } > attributes #1 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+fxsr,+mmx,+x87,+sse,+sse2,+sse3" } > attributes #2 = { noinl...

...2012, at 3:50 PM, Joe Groff wrote: > Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT > routine _ftol2 for floating-point to unsigned conversions, but this > function has a nonstandard calling convention LLVM doesn't understand. > It takes its input operand on the x87 stack as ST0, which it pops off > of the stack before returning. The return value is given in EDX:EAX. > In effect, I need to call it like this: > > %1 = call i64 asm "call __ftol2", > "=A,{st},~{dirflag},~{fpsr},~{flags}" (double %x) nounwind > > but with...

> You may also need to turn off some cpu attributes like SSE, I don't recall, see >   llc -mcpu=help test.ll Maybe it'd be easier at dragonegg level -mfpmath=sse / x87 - and compare the results -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

This patch adds a number of fp instructions needed for OS/2 to boot as a HVM guest on Intel/VT hardware. It appears to work fine, and OS/2 is now finally working on Intel/VT as well as AMD/SVM. I''m a little concerned about the "correctness" of the FSTSW emulation and the use of inline assembly directly using the corresponding ops for emulation. Wrt FSTSW, it is really two ops

...rd-wired in. Note that it's not just about alignment, but mainly about the reserved storage size. > I'm not sure how hard this would be to control via a > command line option (i.e. -m96bit-long-double). Is there no different way to go about this? Our compiler currently supports the x87 long double type as a) 10 bytes, for Turbo Pascal and Delphi-compatibility b) 12 bytes, for non-Darwin ABI/C x86 compatibility c) 16 bytes, for Darwin x86 ABI/C and x86_64 ABI/C compatibility long doubles of type a) and c), or of type b) and c), can occur in the same compilation unit. A command li...

...uot;no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" } attributes #1 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame...