search for: fdivs

Hi Andy, Dave, I've been doing a bit of experimentation trying to understand the schedmodel a bit better and improving modelling of FDIV (on Cortex-A57). FDIV is not pipelined, and blocks other FDIV operations (FDIVDrr and FDIVSrr). This seems to be already semi-modelled, with a "ResourceCycles=[18]" line in the SchedWriteRes for this instruction. This doesn't seem to work (a poor schedule is produced) so I changed it to also require another resource that I modelled as unbuffered (BufferSize=0), in the hope t...

I would like to transform X/Y -> X*1/Y. Specifically, I would like to convert: define void @t1a(double %a, double %b, double %d) { entry: %div = fdiv fast double %a, %d %div1 = fdiv fast double %b, %d %call = tail call i32 @foo(double %div, double %div1) ret void } to: define void @t1b(double %a, double %b, double %d) { entry: %div = fdiv fast double 1.000000e+00, %d %mul = fmul

On 08.08.2013, at 18:25, Chad Rosier <chad.rosier at gmail.com> wrote: > I would like to transform X/Y -> X*1/Y. Specifically, I would like to convert: > > define void @t1a(double %a, double %b, double %d) { > entry: > %div = fdiv fast double %a, %d > %div1 = fdiv fast double %b, %d > %call = tail call i32 @foo(double %div, double %div1) > ret void >

Hello, I have a question about the constant folding for fdiv instructions. For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I think this should be nan. Can anyone tell me why it is not nan? Thanks. Leo _________________________________________________________________ Exercise your brain! Try Flexicon.

I did few transformation in Instruction *InstCombiner::visitFDiv() in an attempt to remove some divs. I may miss this case. If you need to implement this rule, it is better done in Instcombine than in DAG combine. Doing such xform early expose the redundancy of 1/y, which have positive impact to neighboring code, while DAG combine is bit blind. You should be very careful, reciprocal is very

Hi Chad, This is a great transform to do, but you’re right that it’s only safe under fast-math. This is particularly interesting when the original divisor is a constant so you can materialize the reciprocal at compile-time. You’re right that in either case, this optimization should only kick in when there is more than one divide instruction that will be changed to a mul. I don’t have a strong

I remember why I didn't implement this rule in Instcombine. It add one instruction. So, this xform should be driven by a redundancy eliminator if you care code size. On 8/8/13 10:13 AM, Shuxin Yang wrote: > I did few transformation in Instruction *InstCombiner::visitFDiv() in > an attempt to remove some divs. > I may miss this case. If you need to implement this rule, it is >

Hey guys, I am wondering what the semantics for fdiv is, if the denominator is zero. For sdiv, the language reference specifies that this is undefined behavior. For fdiv, the language reference says nothing (hence, I assume that it is defined somehow). So how is it defined? Does it follow IEEE-754 definition, i.e., +Inf if nominator is > 0, -Inf if nominator is < 0, otherwise NaN?

Hi, Consider the following test case: int foo(float *A, float *B, float *C, int len, int VSMALL) { for (int i = 0; i < len; i++) if (C[i] > VSMALL) A[i] = B[i] / C[i]; } In this test the div operation is conditional but llvm is generating unconditional div for this case: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [

On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: > Hello, I have a question about the constant folding for fdiv instructions. > For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I > think this should be nan. Can anyone tell me why it is not nan? I think the specification says that it is "undefined" so any value will do. inf is just as undefined

I believe we were under the impression that InstCombine, as a canonicalized/optimizer, should not increase code size but only reduce it. Minor aside, but you don't need all of fast-math for the IR, just the "arcp" flag, which allows for replacement of division with reciprocal-multiply. On Aug 8, 2013, at 10:21 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > I remember

Yes, if %x is a NaN, we should expect that NaN is propagated. I'm still not sure what to do here. We can take comfort in knowing that whatever we do is likely an improvement over the current situation though. :) That's because the code in InstSimplify is inconsistent with the LangRef: http://llvm.org/docs/LangRef.html#undefined-values (UB for fdiv by 0?) ...and both of those are

Seems incorrect but I forget the IEEE fp rules. What if both x and y are infinity? in that case x/y = NAN but you transformation will yield 0 as the result. On 08/08/2013 09:25 AM, Chad Rosier wrote: > I would like to transform X/Y -> X*1/Y. Specifically, I would like to > convert: > > define void @t1a(double %a, double %b, double %d) { > entry: > %div = fdiv fast

Reid Spencer wrote: > On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: > >> Hello, I have a question about the constant folding for fdiv instructions. >> For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I >> think this should be nan. Can anyone tell me why it is not nan? >> > > I think the specification says that it is

%y = fadd float %x, undef Can we simplify this? Currently in IR, we do nothing for fadd/fsub/fmul. For fdiv/frem, we propagate undef. The code comment for fdiv/frem says: "the undef could be a snan" If that's correct, then shouldn't it be the same for fadd/fsub/fmul? But this can't be correct because we support targets that don't raise exceptions...and even targets

On Aug 8, 2013, at 9:56 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Chad, > > This is a great transform to do, but you’re right that it’s only safe under fast-math. This is particularly interesting when the original divisor is a constant so you can materialize the reciprocal at compile-time. You’re right that in either case, this optimization should only kick in when

Jeff Cohen wrote: > Reid Spencer wrote: >> On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: >> >>> Hello, I have a question about the constant folding for fdiv instructions. >>> For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I >>> think this should be nan. Can anyone tell me why it is not nan? >>>

I’m not sure the transformation happening with fdiv is correct. If we have “%y = fdiv float %x, undef” and %x is a NaN then the result will be NaN for any value of the undef, right? So if I understand the undef rules correctly (never a certainty) then we can’t safely replace the expression with undef. We could, I think, replace it with “%y = %x” though. I think the same is true for fadd, fsub,

Why is NaN “just ‘undef’ in IR”? NaN is a specific value with well-defined behavior. I would think that unless the no-NaNs flag is used we need to preserve the behavior of NaNs. From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Wednesday, February 28, 2018 12:08 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes

All llvm-devs, We're going to introduce the new possible implementation for such optimizations as reciprocal estimation instead of fdiv. In short it's a replacement of fdiv instruction (which is very expensive in most of CPUs) with alternative sequence of instructions which is usually cheaper but has appropriate precision (see genReciprocalDiv in lib/Target/X86/X86InstrInfo.cpp for