similar to: [LLVMdev] Floating point instructions patch

On Thu, 28 Apr 2005, Morten Ofstad wrote: > I have been gone for a while, finishing work on my Master's thesis... Hi Morten, congrats! :) > Now that I'm back I updated LLVM to the most recent version and found > that my FP_ABS SelectionDAGNode type and code generation was now > conflicting with the new FABS node type. I brought the rest of my local > modifications in

Chris Lattner wrote: > The patches I didn't apply are these: > > 1. Match (Y < 0) ? -Y : Y -> FABS in the SelectionDAGISel.cpp file. We > already catch this at the DAG level. If we aren't, please let me know. OK, no problem - I was just told last time I tried to get my patch in that this was needed because the C++ frontend generated this code, I'm generating

New patch here -- it's not been tested yet because we're having some problems with the application (I can't create new VM programs at the moment), but it compiles OK ;-) Please look over it and see if there are some more changes you'd like me to make before you can commit it... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed...

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 simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

Hello, I'm currently adding the floating point math instructions (fabs, fsin, fcos ...) to the x86 instruction set. I'm a bit unsure how to make the back end actually generate these instructions, though. My current plan is to add llvm intrinsics for these instructions but I've noticed that llvm already handles C math library functions to some extent. It feels a bit strange to add

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 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

HI developers, I want to add trigonometric instructions in my instrinfo.td files how can i directly map these instructions in .td files. Please help me Guys.For Sin, Cos, Tan and Cot Instructions. If I used llvm.sin.* as SDNode Then it is error as llvm variable is not defined SO please Help me. Thanks and Regards Varun -------------- next part -------------- An HTML attachment was scrubbed...

On Tue, Apr 15, 2014 at 12:33 PM, Peter Meerwald <pmeerw at pmeerw.net> wrote: > Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> > --- > libspeexdsp/resample.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c > index e32ca45..a19b997 100644 > ---

Hello, Is there a way of generating unary floating point operations (like ISD::FABS, ISD::FSIN, ...) from C code using clang? I am building a backend for a machine that has hw support for these ops and I need a way to test them. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, some misc. cleanup patches for speexdsp, nothing big I'm not sure about how to submit patches, so this is a test balloon :) ultimately, I'd like to fix the FIXED_POINT issue, see http://lists.xiph.org/pipermail/speex-dev/2013-December/008465.html currently, I think the only way to find out how speexdsp has been compiled is to resample some bytes and observe the output; which is

Hello everyone, I'd like to propose the attached patch to form FMA intrinsics aggressively, but in order to do so I need some clarification on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below: UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introducing illegal (not

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 > simplification.  There are still some issues with this patch, but does > the approach

Chris Lattner wrote: > The way to deal with this is to add LLVM intrinsics, but only for > functions that set errno. For example, you could add llvm.sqrt, which > is just undefined on a negative value other than -0.0. For your uses, > you just emit llvm.sqrt, the C frontend will make use of it and wrap > errno handling around it as required. > > For functions like

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

Hi Owen, Having looked into this due to Clang failing PlumHall with it recently I can give an opinion... I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If c == d, it is still possible for that result not to equal a*b, as "+c

Hello, I am following up on the issue discussed at the SVE meeting, Sander mentioned that there were some patterns missing from SVE CodeGen for floating point operations, but I was unable to identify them. He mentioned something about looking at the ISelLowering for AArch64 to identify them, so if there is any information of that regard it would be greatly appreciated so we can contribute with

On Tue, 4 Jan 2005, Morten Ofstad wrote: > I'm currently adding the floating point math instructions (fabs, fsin, fcos > ...) to the x86 instruction set. Cool! > I'm a bit unsure how to make the back end actually generate these > instructions, though. My current plan is to add llvm intrinsics for > these instructions but I've noticed that llvm already handles C