On Tue, 3 May 2011, Mike Stump wrote: > And to go one step further, if we had this, we could use this to define > all data manipulation machine built-ins as generic functions, available > to all compiles as normal c code, so portable code could use them > everywhere, and on platforms that had instructions for any of them, they > could define them as normal built-ins.
I don't think the forms in which some of the machine-specific built-in functions exist are particularly good for being available everywhere - they are typically defined to correspond exactly to the defined semantics of a particular instruction, complete with e.g. the peculiarities of how overflow works for that instruction. But: * I think it does make sense to make a range of vector operations, saturating operations (see the discussion in PR 48580) etc. available as generic GNU C on all platforms, with generically defined semantics (consistent with how C generally handles things such as overflow), where instruction sets commonly have relevant instructions but it isn't readily possible to represent the operations with generic C and pattern-match them. (Just as we provide operations such as __builtin_popcount and __builtin_clz, for example - and note that __builtin_clz has undefined value at 0 rather than being defined to match a machine instruction.) * Once the operations have generic GNU C, GIMPLE and RTL descriptions, intrinsic headers should best use the GNU C representations if possible instead of calling built-in functions, and any built-in functions should expand to the generic GIMPLE and RTL instead of using UNSPECs. * It may also make sense for a target architecture to define its intrinsics in such a way that they are available on that architecture even when the relevant instructions aren't available in a particular subarchitecture. This may be defining the intrinsics in a header if those are the public interface, instead of the built-in functions. See a thread starting at <http://gcc.gnu.org/ml/gcc/2010-11/msg00546.html> for some discussion of doing this for SSE, for example. -- Joseph S. Myers jos...@codesourcery.com
