Hi, > It's just a different name, nothing more, nothing less. Because it is > a different name it can not be accidentally generated from actual > truncations.
I have introduced float_narrow but I could not find appropriate places to generate it for a call to fadd instead it to generate a CALL. I used GDB to set breakpoints which hit fold_rtx and cse_insn but I got confused with the rtx codes and passes which generate respective RTL. It should not be similar to FLOAT_TRUNCATE if we want to avoid it generating for actual truncations? Thanks, Tejas On Fri, 16 Aug 2019 at 15:53, Richard Sandiford <richard.sandif...@arm.com> wrote: > > Segher Boessenkool <seg...@kernel.crashing.org> writes: > > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford 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 > > > > I like that "float_narrow" name :-) > > > >> > 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. > > > > How so? It would *mean* there is only single rounding, even! That's > > the whole point of it. > > But a PLUS should behave as a PLUS in any context. Making its > behaviour dependent on the containing rtxes (if any) would be a > can of worms. > > Richard
