similar to: [LLVMdev] gmake check failures on FreeBSD

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

Update: I have been working on this all day, and I finally got it working more or less with the pattern instruction selector... However, the generated code is not very good, and I haven't implemented the expand to calls if the target does not support these FP instructions. As an example, in the following function the sub abs and compare compiles to 13 instructions! Also it has changed the

Chris Lattner wrote: > On Wed, 16 Mar 2005, Morten Ofstad wrote: >> The case which emits code for the special case of comparing against >> constant 0.0 does not return after generating it's code, so the normal >> compare is also generated! As far as I can tell it should return right >> after this: >> >> BuildMI(BB, X86::SAHF, 1); >> >>

Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not

Hello, I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work with the X86ISelPattern, but I'm having some difficulties understanding what needs to be done. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

note: whole function is below- I am sure I am doing something silly. when I use it like USGS(input="precipitation") it is choking on the precip.1 <- subset(DF, precipitation!="NA") b <- ddply(precip.1$precipitation, .(precip.1$gauge_name), cumsum) DF.precip <- precip.1 DF.precip$precipitation <- b$.data part, but runs fine outside of the function: days=7

Look at the bottom of the message for my question #here is a little function that I wrote USGS <- function(input="discharge", days=7){ library(chron) library(gsubfn) #021973269 is the Waynesboro Gauge on the Savannah River Proper (SRS) #02102908 is the Flat Creek Gauge (ftbrfcms) #02133500 is the Drowning Creek (ftbrbmcm) #02341800 is the Upatoi Creek Near Columbus (ftbn) #02342500 is

Hello everyone. I'm not an expert neither in llvm nor in x86 nor in IEEE standard for floating point numbers, thus any of my following assumptions maybe wrong. If so, I will be grateful if you clarify me what's goes wrong. But if my guesses are correct we possibly have a bug in fp arithmetics on x86. I have the following ir: @g = constant i64 1 define i32 @main() { %gval = load

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

All, I'm working on a new scheduler and have encountered this assert isNew && "Node emitted out of order - early" I believe that it occurs when I clone a compare/test instruction. I've looked at the SUnit graph and the units are scheduled correctly. Any advice is appreciated. Aran

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

2013/10/19 Rafael Espíndola <rafael.espindola at gmail.com>: > On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: >> I found that access llvm-mc from clang driver is impossible, and I >> want to use llvm-mc to compile assembly files, how to do that? > > Try "clang -integrated-as -c test.s" Thank you very much, I use the

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

I can confirm I get the same behavior, and that's a real bug. If you use --target=i686-pc-win32, you get COFF, and that should be a good workaround for now. There must be a conditional somewhere that isn't handling mingw correctly. On Sat, Oct 19, 2013 at 7:58 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > 2013/10/19 Rafael Espíndola <rafael.espindola at

Jean-Marc Valin wrote: >If you set the denoiser to "on" and the VAD to "off", what difference >does it make in CPU time? > <p>Same program, running on Athlon XP 1700+: Test 1, using VAD, but AGC, denoise off: tevek@canarsie:~/work/hms/app_conference $ time ./vad_test /tmp/demo-instruct.sw 5 reading from /tmp/demo-instruct.sw, repeating 5 times read 537760

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > I found that access llvm-mc from clang driver is impossible, and I > want to use llvm-mc to compile assembly files, how to do that? Try "clang -integrated-as -c test.s" Cheers, Rafael