Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Fri, 27 Nov 2015, Joseph Myers wrote:

> > I find it highly unlikely though that the writers will (be able to) chase 
> > individual targets and any obscure hardware-dependent options the targets 
> > may provide.  And we cannot expect people compiling software to be 
> 
> What that says to me is that there should be an architecture-independent 
> option (-fieee?) that, for architectures where the default configuration 
> may have architecture-specific deviations from the normal defaults 
> regarding conformance to IEEE 754 language bindings but there are options 
> to disable those deviations, disables those deviations.  For example, on 
> alpha that would imply -mieee-with-inexact.  On architectures without such 
> issues (beyond bugs that should be fixed unconditionally, not conditional 
> on a command-line option, or issues with the hardware ISA that are 
> infeasible to fix in software), that option would do nothing (beyond any 
> architecture-independent effects it might have such as implying 
> -fno-fast-math).

 I'm fine with `-fieee'/`-fno-ieee', and corresponding 
`--with-ieee=yes/no' configuration options.

 I have been aware of the Alpha processor's imprecise IEEE 754 exception 
mode and while working on the specification concerned here I had in my 
mind the possibility of expanding the semantics of the MIPS target's 
`-mieee=' option to cover the somewhat similar imprecise IEEE 754 
exception mode of the MIPS R8000 processor, or any optimisations of the 
same or a different kind the MIPS architecture might introduce in the 
future.

 Since (regrettably) by now the Alpha architecture has become a legacy one 
I didn't consider it important enough to create a generic option which 
would only control the Alpha target, in addition to the MIPS target being 
considered here.  So I am actually glad you proposed it as I agree it will 
make things cleaner.

> >  As you may see in the GCC patches I have just posted the `-mieee=strict' 
> > option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none', 
> > the only target-specific option so far.  So this does exactly what I 
> > outlined above.
> 
> I am doubtful about the architecture-specific option setting 
> architecture-independent options here.  Having it the other way round as I 
> suggested above would make more sense to me.

 Agreed, as noted above.

> > "Any or all of these options may have effects beyond propagating the IEEE 
> > Std 754 compliance mode down to the assembler and the linker.  In 
> > particular `-mieee=strict' is expected to produce strictly compliant code, 
> > which in the context of this specification is defined as: following IEEE 
> > Std 754 as closely as the programming language binding to the standard 
> > (defined in the relevant language standard), the compiler implementation 
> > and target hardware permit.  This means the use of this option may affect 
> > code produced in ways beyond NaN representation only."
> > 
> > > >  Does this answer address your concerns?
> > > 
> > > No, the option concept as described seems too irremediably vague.
> > 
> >  Does this explanation give you a better idea of what I have in mind?  Do 
> > you still have concerns about the feasibility of the idea?
> 
> It's better defined, but I think it would be better for -fieee to imply 
> -mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict 
> to imply architecture-independent options.  Cf. i386 and sh where 
> -ffinite-math-only affects architecture-specific options.

 Thanks for the references.  I'll have a look in the course of updating 
the implementation.

 With `-fieee' in the picture I think we can get rid of GCC's 
target-specific high-level `-mieee=' option, as having become redundant, 
and retain the low-level `-mrelaxed-nan=' only, with the assumption that 
only power users will need to control this setting directly and they will 
necessarily have studied and understood all the implications.  Additional 
low-level options can be added in the future as needed to control the 
R8000 exception mode or other architectural features affecting IEEE 754 
arithmetic, wired to `-fieee' as appropriate.

 I'm going to retain the assembler and linker options and directives of 
the `*ieee*' form though as their purpose is a bit different -- to set 
flags in a binary file rather than affecting code generation -- and I 
don't think it makes sense to expand the namespace there.  The effects of 
these options are cumulative rather than mutually exclusive and it's the 
names of individual bits or enumeration fields within binary file's 
control structures, referred in the option's or directive's argument, that 
tell features apart.

 I'll be updating the specification and the proposed implementation 
shortly, and I also think the addition of `-fieee' will then better be 
done as a separate preparatory change, initially affecting the Alpha 
target only.  Please let me know if I missed anything, or if you have any 
other questions or comments.

 Thank you for your input, and Happy New Year!

  Maciej