RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Joseph Myers <joseph@codesourcery.com>writes:
> On Thu, 15 May 2014, Matthew Fortune wrote:
> 
> > > That suggests you need a new -mlink-require-msa or similar option to
> put
> > > this setting in an executable / shared library, given that existing
> > > practice is that use of an option such as -mmsa for some objects does
> not
> > > imply an MSA requirement for the result of linking - users don't expect
> to
> > > need any special options for code with that sort of runtime checking,
> they
> > > just build different objects with different options (and you're
> unlikely
> > > to get -mmsa used for all objects in any executable / shared library -
> if
> > > nothing else, crt*.o, libgcc etc. probably aren't built with -mmsa - so
> > > merging on the basis that MSA + non-MSA = non-MSA won't help).
> >
> > Binutils is tuned for the simple case of users writing code that does not
> do
> > runtime checks. i.e. as foo.s -mmsa results in an object that says it
> uses
> > the MSA ASE. The merging of ASE usage into an executable or shared
> library
> > is an 'OR' so MSA + non-MSA == MSA. To create a shared library or
> executable
> > which includes runtime checks before executing any MSA code then the MSA
> > code has to be hidden:
> >
> > as foo.s
> > ===
> > .set push
> > .set msa
> > <msa function>
> > .set pop
> > ===
> >
> > The resulting object will then 'not' be marked as using the MSA ASE.
> 
> That indicates to me that the GCC -mmsa option should not imply the
> assembler -mmsa option, so that users can use -mmsa with GCC exactly the
> same way they use -mavx (for example) - that is, -mmsa should result in
> the push/pop in the .s file.  Otherwise, how do you expect users compiling
> one source file with -mmsa and one without to get their final binary not
> marked as requiring MSA?

I don't currently expect an object built with -mmsa and one without to result
in an executable that does not say it requires MSA. If someone wishes to hide
the usage of an extended architecture feature then that it must be enabled on
a per function basis so that it is clear that they are special. For MSA this
would be done via a function attribute and could be applied for all
functions in a compilation unit too. We have to differentiate between
assumed existence of MSA and smart runtime checks to choose the right function.
I would expect that if someone builds a simd optimised library by just adding
the relevant simd command line flag then this is to build a whole library of
simd not half simd and half generic so it is right and correct to mark that
library as using the simd extension. For those cases where there is some
small usage of simd like ifunc (or a more manual version of ifunc) then the
function annotation to enable MSA is not onerous.

Regarding comparing MSA with AVX...

I don't know for sure but I don't believe the use of AVX can be recorded in
an ELF (at least not in any way that the loader can see) so it is not
necessarily a conscious decision to not mark the ELF, it is arguably a
missing feature.

Related to this is the fact that AVX ABI decisions differ quite
significantly from MSA as MIPS has opted to not extend/change the calling
convention for vector types when targeting MSA. This is specifically to
support having generic code (that may include vector types passed by value)
to be compiled as either MSA or non-MSA and avoid the need for the caller
to know how the target function was compiled. While it is unlikely for
ordinary code to use vector types passed by value MIPS chose to ensure this
case did not cause ABI compatibility issues.

To what extent do you feel the use of an ISA extension must be controlled
via a command line option for the various use cases?

Regards,
Matthew