This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Joseph Myers <joseph@codesourcery.com> writes:
> On Thu, 15 May 2014, Matthew Fortune wrote:
> 
> > > 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
> 
> I consider that a key feature of the GNU toolchain is consistency
> between
> different architectures - meaning that if this sort of thing works on
> pretty much all architectures, MIPS shouldn't be doing something
> different.  (And it *certainly* shouldn't be requiring things to be done
> on a per-function basis.  Even if the command-line option acts
> differently, there should be a command-line option to say that the
> object
> isn't marked as needing MSA - though I'd say it should be the other way
> round, with a -m option to say to mark the object for runtime
> compatibility checks.)

I don't understand the use-case that would want a whole module (and/or
subset of modules within one library) to freely deploy an ISA extension
but have no overall marking to that extent. Such global enablement must be
taken to indicate unconditional usage of an extension. If there is some
real use-case where the result of linking such modules does not want to
be marked appropriately then I see that as the special case. If AVX has
no such feature then it needs improving rather than having all other
architectures gloss over the problem too.

My only assumption is that you envisage a library where pretty much
all entry points are ifunc (or similar) and there are 'n' implementations
of highly complex features that span across multiple source files. Assuming
this were found to be useful (vs the simple ifunc case of small features
being optimised) then it seems better to support it by having the library
built 'n' times with the various supported extensions and have the library
selected as a whole rather than per-function/feature. If nothing else this
will result in lower overall memory footprint as only the code that will be
used gets loaded. It is also a simpler model for those who wish to just
produce libraries of code optimised for different extensions.

I see evidence that ARM provide some support this model of whole library
optimisation by having VFP and NEON HWCAPs part of HWCAP_IMPORTANT. I don't
believe there is any verification that the VFP or NEON optimised libraries
are 'only' found in the relevant search paths but that could be improved.

Checking that the appropriate hardware is available for a library is very
similar to checking that the ABIs used by libraries match. The lack of
such hardware checks currently is the same as there being no checks (in any
arch as far as I can see) that hard and soft float libraries are not mixed.
Therefore all these ideas are new levels of safety for the dynamic linker.

> I suppose that, to the extent that LTO options merging may already cause
> issues when different objects are built with different options, there
> may
> be a case for a -f option meaning "this object uses instruction set
> extensions in functions that may or may not be used at runtime, do not
> automatically use those options for other objects in this link and do
> not
> count those extensions for runtime compatibility checks".

That's an equally complex case but also solvable by clearly annotating the
source with what extensions should be used when building certain functions.
Surely that is the expected way of deploying ifunc optimised C-code.

Regards,
Matthew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]