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, midlevel]: Handle (int)trunc(float x) cases


Uros Bizjak <uros@kss-loka.si> writes:

> Roger Sayle wrote:
> 
> >Sorry for the delay in reviewing but I've been investigating the
> >asymmetry between trunc and the other integer rounding functions;
> >round, floor and ceil.  The following code from expr.c explains a
> >lot:
> >
> >
> >>>   case FIX_ROUND_EXPR:
> >>>   case FIX_FLOOR_EXPR:
> >>>   case FIX_CEIL_EXPR:
> >>>     gcc_unreachable ();                       /* Not used for C.  */
> >>>
> >>>   case FIX_TRUNC_EXPR:
> >>>     op0 = expand_expr (TREE_OPERAND (exp, 0), NULL_RTX, VOIDmode, 0);
> >>>     if (target == 0 || modifier == EXPAND_STACK_PARM)
> >>>       target = gen_reg_rtx (mode);
> >>>     expand_fix (target, op0, unsignedp);
> >>>     return target;
> >>>
> >
> >So although tree codes are defined for the other "fix" conversions,
> >it's clearly unsafe to use them.  It's not clear what the best way
> >to clean this up is (either add to add the missing support or to
> >remove the partially implemented tree codes).  An issue for another
> >day...
> >
> >
> I have been trying to implement these conversions in the same way as
> FIX_TRUNC_EXPR (looking at the same code as you quote above). But to
> implement these conversion as fix_trunc[INTmode][FPmode] optab, a lot
> of expanders would be needed.

You should be able to write only one expander, and have optabs.c know
that if there's no [SImode][SFmode] it should use [SImode][XFmode] and
if not that either then it should use [DImode][XFmode].

> As a compromise, the same functionality could be acheived by
> implementing only a  fix_floor[INTmode] expanders, where its FPmode
> input is always in widest FP mode (XFmode in i386 case). Please note
> that this expansion is performed in expand_unop. As lfloor and ltrunc
> optabs are enabled only for -ffast-math, where FPmode->XFmode
> conversion is 'free', this results in quite optimal asm code.

No, this isn't a good idea.  It works fine for x86 but most other
ports don't have a 'widest FP mode' that you'd want to use.


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