> > + ----------------------
> > + An alternative approach would be to use a peephole2 pattern to perform
> > this
> > + optimization. However, between "li a0, 0" and "cm.popret", there can be
> > + STACK_TIE and other instructions that make it difficult to write a
> > robust
> > + peephole pattern that handles all cases.
> I could formulate this as a delay slot filling problem. I'm not saying
> we should, but I've solved similar problems using that framework in the
> past. Essentially we claim that the popret has a delay slot and only
> allow it to be filled with a li a0, 0. You then detect that the slot
> was filled during assembly output and emit a popretz instead. It's *gross*.
Thanks for the suggestion, I will still take current implementation
move forward, but I definitely will spend time on delay slot stuff
since it seems like will be a useful new cool stuff in my tool box :P
>
>
> > + {
> > + if (SET_SRC (def_pat) == const0_rtx)
> You may want to use CONST0_RTX here so that you can capture 0.0 as a
> double precision FP value. You need to know the mode to use CONST0_RTX,
> so you'd probably need to capture the mode from the USE statement. I
> would certainly understand if you don't think it's worth the effort.
CONST0_RTX can catch a few more cases for soft float ABI, Thanks!
> You may also want to consider a limit on the number of instructions you
> examine. You could have large BBs in play that will cause a
> compile-time explosion (made the same mistake myself in the past)...
I am less concerned about this since we check exit block's pred only,
although that might still cause compile time issues in extreme cases.
>
> So OK with or without the two minor issues above addressed.
>
> Jeff
