[Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

James Greenhalgh james.greenhalgh@arm.com
Mon Oct 3 08:31:00 GMT 2016


On Fri, Sep 30, 2016 at 05:57:45PM +0000, Joseph Myers wrote:
> On Fri, 30 Sep 2016, Jeff Law wrote:
> 
> > On 09/30/2016 11:34 AM, Joseph Myers wrote:
> > > On Fri, 30 Sep 2016, James Greenhalgh wrote:
> > > 
> > > > +      case EXCESS_PRECISION_TYPE_STANDARD:
> > > > +      case EXCESS_PRECISION_TYPE_IMPLICIT:
> > > > +	/* Otherwise, the excess precision we want when we are
> > > > +	   in a standards compliant mode, and the implicit precision we
> > > > +	   provide can be identical.  */
> > > > +	return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;
> > > 
> > > That's wrong for EXCESS_PRECISION_TYPE_IMPLICIT.  There is no implicit
> > > promotion in the back end (and really there shouldn't be any excess
> > > precision here at all, and double_t in glibc should be fixed along with a
> > > GCC change to remove this mistake).
> > Sorry, change to a NAK.
> > 
> > Joseph, what's the right thing to do here?
> 
> (a) The present patch would keep the existing value of FLT_EVAL_METHOD.  
> But the existing value is inaccurate for the default compilation mode, 
> when there is no implicit promotion in the back end, and doing so means 
> suboptimal code in libgcc and glibc because it does things to handle 
> excess precision that isn't actually there (and quite possibly in code 
> elsewhere that looks at FLT_EVAL_METHOD).
> 
> (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like 
> EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end 
> does.  It would mean that the default FLT_EVAL_METHOD is 0, which is a 
> more accurate description of how the compiler actually behaves, and would 
> avoid the suboptimal code in libgcc and glibc.  It would however mean that 
> unless -fexcess-precision=standard is used, FLT_EVAL_METHOD (accurate) is 
> out of synx with float_t in math.h (inaccurate).
> 
> (c) Removing all special excess precision for S/390 from GCC, and changing 
> float_t to float in glibc, is logically correct and produces optimal code.  
> float_t does not appear in the ABI of any glibc function; in principle it 
> could affect the ABIs of other libraries, but I don't think that's 
> particularly likely.
> 
> The only argument for (a) is that's it's semantics-preserving - it's just 
> that the preserved semantics are nonsensical and involve an inaccurate 
> value of FLT_EVAL_METHOD in the default compilation mode.

I'm happy progressing whichever of a) or b) would be preferred by the
the s390 maintainers. But I'd be uncomfortable making the wider changes
in c) as I've got no access to an s390 build and test environment in which
I have any confidence, nor do I know the s390 port history that led to the
'typedef double float_t' in glibc.

Regardless of which approach is chosen, I'll be sure to update the patch
with a comment paraphrasing your suggestions above.

Thanks,
James



More information about the Gcc-patches mailing list