On Tue, 2012-12-11 at 11:15 +0100, Andreas Krebbel wrote:
> On 11/12/12 10:16, Kaz Kojima wrote:
> > Andreas Krebbel <kreb...@linux.vnet.ibm.com> wrote:
> >> urgs - I'll fix this. Is the patch ok with that change for sh?
> >
> > Yes, the sh portion is OK with that change, though it would be better
> > to fix the users of sh_canonicalize_comparison instead of its wrapper
> > as pointed out by rth and oleg.
>
> For the backend internal uses sh_canonicalize_comparison has an additional
> 'mode' parameter. It is
> not clear to me why this is actually needed. But "fixing" the users would
> involve getting rid of
> this parameter. I didn't want to change that with this patch since it might
> change the original
> behaviour. The patch hopefully is a NOP for the change back-ends.
>
The mode is used to do e.g.
/* unsigned x > 0x7FFFFFFF --> signed x < 0
unsigned x <= 0x7FFFFFFF --> signed x >= 0 */
which only works for SImode. The mode parameter is passed to
sh_canonicalize_comparison by prepare_cbranch_operands which is invoked
by the cbranchdi4 expander, by expand_cbranchsi4 and by
expand_cbranchdi4. When sh_canonicalize_comparison is invoked by
combine the mode is set to VOIDmode and the function will try to use the
mode of the operands instead. Probably that would also be sufficient
when it is being used during cbranch expansion, as the operands will
have a mode. I've not tried out doing that though when I refactored
those pieces a while ago.
I think fixing the users of sh_canonicalize_comparison should be done
after the int* vs. rtx_code thing has been figured out. Otherwise, we'd
have to add casts in a couple of places (int* vs rtx_code*) and remove
them again afterwards.
Cheers,
Oleg
