Macros |
#define | DEF_RTL_EXPR(V, N, X, C) #V, |
#define | OPTAB_CL(name, pat, c, b, l) name, |
#define | OPTAB_CX(name, pat) |
#define | OPTAB_CD(name, pat) name, |
#define | OPTAB_NL(name, pat, c, b, s, l) name, |
#define | OPTAB_NC(name, pat, c) name, |
#define | OPTAB_NX(name, pat) |
#define | OPTAB_VL(name, pat, c, b, s, l) name, |
#define | OPTAB_VC(name, pat, c) name, |
#define | OPTAB_VX(name, pat) |
#define | OPTAB_DC(name, pat, c) name, |
#define | OPTAB_D(name, pat) name, |
#define | NS "NULL" |
#define | ZS "'\\0'" |
#define | OPTAB_CL(o, p, c, b, l) { #o, p, #b, ZS, #l, o, c, UNKNOWN, 1 }, |
#define | OPTAB_CX(o, p) { #o, p, NULL, NULL, NULL, o, UNKNOWN, UNKNOWN, 1 }, |
#define | OPTAB_CD(o, p) { #o, p, NS, ZS, NS, o, UNKNOWN, UNKNOWN, 2 }, |
#define | OPTAB_NL(o, p, c, b, s, l) { #o, p, #b, #s, #l, o, c, c, 3 }, |
#define | OPTAB_NC(o, p, c) { #o, p, NS, ZS, NS, o, c, c, 3 }, |
#define | OPTAB_NX(o, p) { #o, p, NULL, NULL, NULL, o, UNKNOWN, UNKNOWN, 3 }, |
#define | OPTAB_VL(o, p, c, b, s, l) { #o, p, #b, #s, #l, o, c, UNKNOWN, 3 }, |
#define | OPTAB_VC(o, p, c) { #o, p, NS, ZS, NS, o, c, UNKNOWN, 3 }, |
#define | OPTAB_VX(o, p) { #o, p, NULL, NULL, NULL, o, UNKNOWN, UNKNOWN, 3 }, |
#define | OPTAB_DC(o, p, c) { #o, p, NS, ZS, NS, o, c, c, 4 }, |
#define | OPTAB_D(o, p) { #o, p, NS, ZS, NS, o, UNKNOWN, UNKNOWN, 4 }, |
#define OPTAB_CL |
( |
|
name, |
|
|
|
pat, |
|
|
|
c, |
|
|
|
b, |
|
|
|
l |
|
) |
| name, |
The entries in optabs.def are categorized: C: A "conversion" optab, which uses two modes; has libcall data. N: A "normal" optab, which uses one mode; has libcall data. D: A "direct" optab, which uses one mode; does not have libcall data. V: An "oVerflow" optab. Like N, but does not record its code in code_to_optab.
CX, NX, VX: An extra pattern entry for a conversion or normal optab.
These patterns may be present in the MD file with names that contain the mode(s) used and the name of the operation. This array contains a list of optabs that need to be initialized. Within each name, $a and $b are used to match a short mode name (the part of the mode name not including `mode' and converted to lower-case).
$I means that only full integer modes should be considered for the next mode, and $F means that only float modes should be considered. $P means that both full and partial integer modes should be considered. $Q means that only fixed-point modes should be considered.
The pattern may be NULL if the optab exists only for the libcalls that we plan to attach to it, and there are no named patterns in the md files.
#define OPTAB_CL |
( |
|
o, |
|
|
|
p, |
|
|
|
c, |
|
|
|
b, |
|
|
|
l |
|
) |
| { #o, p, #b, ZS, #l, o, c, UNKNOWN, 1 }, |
The entries in optabs.def are categorized: C: A "conversion" optab, which uses two modes; has libcall data. N: A "normal" optab, which uses one mode; has libcall data. D: A "direct" optab, which uses one mode; does not have libcall data. V: An "oVerflow" optab. Like N, but does not record its code in code_to_optab.
CX, NX, VX: An extra pattern entry for a conversion or normal optab.
These patterns may be present in the MD file with names that contain the mode(s) used and the name of the operation. This array contains a list of optabs that need to be initialized. Within each name, $a and $b are used to match a short mode name (the part of the mode name not including `mode' and converted to lower-case).
$I means that only full integer modes should be considered for the next mode, and $F means that only float modes should be considered. $P means that both full and partial integer modes should be considered. $Q means that only fixed-point modes should be considered.
The pattern may be NULL if the optab exists only for the libcalls that we plan to attach to it, and there are no named patterns in the md files.
Read the machine description.
Sort the collected patterns.
Now that we've handled the "extra" patterns, eliminate them from
the optabs array. That way they don't get in the way below.
Sort the (real) optabs. Better than forcing the optabs.def file to
remain sorted by kind. We also scrogged any real ordering with the
purging of the X patterns above.
Emit the optab enumeration for the header file.
Perform a binary search on a pre-encoded optab+mode*2.
??? Perhaps even better to generate a minimal perfect hash.
Using gperf directly is awkward since it's so geared to working
with strings. Plus we have no visibility into the ordering of
the hash entries, which complicates the pat_enable array.
C++ (even G++) does not support (non-trivial) designated initializers.
To work around that, generate these arrays programatically rather than
by our traditional multiple inclusion of def files.