similar to: [LLVMdev] Problems expanding fcmp to a libcall

On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > I'm trying to write a backend for a target with no hardware floating > point support. I've added a single i32 register class. I'm wanting all > floating point operations to be lowered to library function calls. For > the most part LLVM seems to get this right. For example > > define double @div(double %a, double

Evan Cheng wrote: > On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > >> I'm trying to write a backend for a target with no hardware floating >> point support. I've added a single i32 register class. I'm wanting all >> floating point operations to be lowered to library function calls. For >> the most part LLVM seems to get this right. For example

On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >> >>> I'm trying to write a backend for a target with no hardware floating >>> point support. I've added a single i32 register class. I'm wanting >>> all >>> floating point operations to be lowered to

Evan Cheng wrote: > On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>> >>> >>>> I'm trying to write a backend for a target with no hardware floating >>>> point support. I've added a single i32 register class. I'm

On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >> >> >>> Evan Cheng wrote: >>> >>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>>> >>>> >>>>> I'm trying to write a backend for a target with no hardware

Evan Cheng wrote: > On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >>> >>> >>> >>>> Evan Cheng wrote: >>>> >>>> >>>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote:

On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: >> >> This seems to break the convention. It should be the responsibility >> of the caller to further legalize the results. >> >> Evan > That makes sense. In that case I believe > SelectionDAGLegalize::LegalizeSetCCOperands > should be legalizing the result. The description of this function > says

Evan Cheng wrote: > On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: > >>> This seems to break the convention. It should be the responsibility >>> of the caller to further legalize the results. >>> >>> Evan >>> >> That makes sense. In that case I believe >> SelectionDAGLegalize::LegalizeSetCCOperands >> should be

> On Apr 29, 2015, at 2:33 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > >> On Apr 29, 2015, at 10:06 AM, Silviu Baranga <Silviu.Baranga at arm.com <mailto:Silviu.Baranga at arm.com>> wrote: >> >> Note that dividing by an integer constant should be a cheap operation >> compared to FP multiplication and comparison as this would get lowered to a

Hi, We seem to have found a bug in the LLVM 3.8 code generator. We are using MCJIT and have isolated working.ll and broken.ll after middle-end optimizations -- in the block merge128, notice that broken.ll has a fcmp une comparison to zero and a jump based on that branch: merge128: ; preds = %true71, %false72 %_rtB_724 = load %B_repro_T*, %B_repro_T**

I am having a little trouble with the fcmp one instruction on doubles only. For ordered comparisons, the LLVM manual states that true should be returned iff neither operands is QNAN. ( http://llvm.org/docs/LangRef.html#i_fcmp) If I do fcmp one which includes one or both operands as a NaN, the result is expected to be 0 then. If I run the bitcode with lli (JIT off), no problem. If I use the

Hi all, I was wondering if it is possible to match the icmp and fcmp assembly language instructions in the code generator. For example, for the following code: %cmp = icmp sgt i32 %tmp, %tmp1 ; <i1> [#uses=1] br i1 %cmp, label %if.then, label %if.else We would like to see something like: SGT cmp, tmp, tmp1 BR cmp lbl However, I can't see any case in the back-ends

Hi, I'm trying expand the Float2Int pass in order to make it able to optimize expressions like f * x > y, where x and y are integers (we'll assume unsigned for simplicity) and f is a floating point constant. The optimization would convert the expression to something like: (a * x)/b > y where a and b are integers guessed by the compiler (currently using continued

Hi, I’ve been investigating https://bugs.llvm.org/show_bug.cgi?id=43374, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting ARM, in the below code example. int bar(float x) { return x!=x ? 0 : 1; } The C99 standard states in section 7.12.14: """ The relational and equality operators support the usual mathematical

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. Yes, that's the obvious alternative. I don't think we have any strong opinion either way, and fcmp/select is certainly easier to implement. -- Kevin Schoedel, Software Developer,

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

Maybe we can have two versions of the intrinsic function, "ordered" and "unordered", just like fcmp has [1]. Would that work ? [1] - http://llvm.org/docs/LangRef.html#fcmp-instruction On Dec 17, 2012, at 11:14 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com]