This is the mail archive of the
mailing list for the GCC project.
Re: RFD: HAVE_* pattern flags
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 17 Oct 2012 14:39:34 +0000
- Subject: Re: RFD: HAVE_* pattern flags
- References: <email@example.com>
On Tue, 16 Oct 2012, Joern Rennecke wrote:
> - Change the semantics of the HAVE_pattern macros for officially named
> patterns so that they are defined as 0 when the pattern is not provided?
> That choice would actually force people to change #ifdef into if (),
> without the possibility of #if, where targets can have non-constant
> pattern predicates.
I think that's appropriate.
Note: for patterns that involve a machine mode, I think it's better to
generate a macro (or function) that takes the mode as a parameter. This
is because most references to modes such as SImode or DFmode in
architecture-independent code are in principle dubious and would need to
be eliminated for ports to unusual architectures with non-8-bit bytes
(rather than being defined in architecture-independent code, it would be
better to have a config/8-bit-byte-modes.def that's used by normal
architectures but not by any future unusual ones).
For example, if such macros / functions are generated automatically,
c-family/c-cppbuiltin.c:mode_has_fma could cease to hardcode a list of
four floating-point modes; instead, the caller could just call the new
HAVE_ macro directly, with the mode as a parameter.
> - We could have a header file that is maintained by hand, with a string
> of #ifdef / #define / #endif .
I think this is probably the simplest and so best approach - just list
those patterns for which the HAVE_* is actually used. Or a text file with
a list, indicating in some way the machine mode parameters to patterns for
which those are relevant.
Joseph S. Myers