search for: fdiv

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

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 fast double %div, %a %mul1 = fmul fast double %div, %...

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 > } > > to: > > define void @t1b(double %a, double %b, double %d) { > entry: > %div = fdiv fast double 1.000000e+00, %d > %mul = fmul...

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. http://games.msn.com/...

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

...d cost function for some targets. -Jim On Aug 8, 2013, at 9:25 AM, 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 > } > > to: > > define void @t1b(double %a, double %b, double %d) { > entry: > %div = fdiv fast double 1.000000e+00, %d > %mul = fmul...

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

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

....splat30 %3 = getelementptr inbounds float, float* %B, i64 %index %4 = bitcast float* %3 to <8 x float>* %wide.masked.load = call <8 x float> @llvm.masked.load.v8f32.p0v8f32(<8 x float>* %4, i32 4, <8 x i1> %2, <8 x float> undef), !tbaa !2, !alias.scope !9 %5 = fdiv <8 x float> %wide.masked.load, %wide.load %6 = getelementptr inbounds float, float* %A, i64 %index %7 = bitcast float* %6 to <8 x float>* call void @llvm.masked.store.v8f32.p0v8f32(<8 x float> %5, <8 x float>* %7, i32 4, <8 x i1> %2), !tbaa !2, !alias.scope !11,...

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 as nan. Reid....

...gt; 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 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...

...agated. 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 inconsistent with undef handling in SDAG. Let me propose an alternate interpretation: 1. The meaning of snan as written in IEEE754-2008 is: "Signaling NaNs afford representations for uninitialized variables..." 2. That matches our intent with 'undef...

...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 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 = fm...

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 "undefined" so any value will > do. inf...

%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 that raise e...

...> > > On Aug 8, 2013, at 9:25 AM, 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 >> } >> >> to: >> >> define void @t1b(double %a, double %b, double %d) { >> entry: >> %div = fdiv fast dou...

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 think the specification says that it is "undefined" so any valu...

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” tho...

...agated. 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 inconsistent with undef handling in SDAG. Let me propose an alternate interpretation: 1. The meaning of snan as written in IEEE754-2008 is: "Signaling NaNs afford representations for uninitialized variables..." 2. That matches our intent with 'undef...

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 details). There are other similar optimiz...