> I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding.
In that case, something like FADD. But for functions like fsub, fmul and fdiv that does similar computation, wouldn't we need more operation codes for them? Is it possible to have something generalized that does *arithmetic computation (rather than just addition)* and then *conversion (narrowing)*? just a thought. Thanks, Tejas On Thu, 15 Aug 2019 at 18:17, Richard Sandiford <richard.sandif...@arm.com> wrote: > > Tejas Joshi <tejasjoshi9...@gmail.com> writes: > > Hello. > > I just wanted to make sure that I am looking at the correct code here. > > Except for rtl.def where I should be introducing something like > > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > > set on functions around expr.c, cfgexpand.c where I grep for > > float_truncate/FLOAT_TRUNCATE did not hit. > > Also, in what manner should float_contract/narrow be different from > > float_truncate as both are trying to do similar things? (truncation > > from DF to SF) > > I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. > > simplify-rtx.c is probably the most important place to handle it. > It would be easiest to test using the selftests at the end of the file. > > Thanks, > Richard
