This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.


> > In the expand:
> >     18: cc:CC_FPU=cmp(r159:DF,r162:DF)
> >     19: r163:SI=cc:CC_FPU<0
> >     20: r161:QI=r163:SI#0
> >     21: r153:SI=zero_extend(r161:QI)
> >     22: cc:CC_ZN=cmp(r153:SI,0)
> >     23: pc={(cc:CC_ZN!=0)?L28:pc}
> >
> > Then after combine we get this:
> >     18: cc:CC_FPU=cmp(r2:DF,r4:DF)
> >        REG_DEAD r4:DF
> >        REG_DEAD r2:DF
> >     23: pc={(cc:CC_ZN<0)?L28:pc}
> >        REG_DEAD cc:CC_ZN
> >        REG_BR_PROB 6102
> 
> That sound like a bug.  Have you looked more closely what's going on?

The fwprop1 is collapsing insn 20 into insn 21. No surprise until here. Then, the combiner is changing first insn 19 and 21 into insn 21 (this seems sane). Followed by combining the resulted insn 21 into insn 22. Finally, insn 22 is changing the condition of the jump (insn 22).
The last steps are a bit too aggressive, but I can make a logic out of it. Practically, insn 22 tells to the combiner how to change a CC_FPU mode into a CC_ZN mode, resulting into the modification of insn 21 to insn23. However, I cannot understand why the combiner chooses for CC_ZN instead of CC_FPU


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]