Fu, Chao-Ying wrote:
+ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
+ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
+ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
+ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
Lots of predefined types and modes in this patch. What about targets
with other requirements (the Blackfin has 40 bit (8 + 32)
accumulators)?
In "bfin-modes.def", we can adjust the DA mode to (s7.32) by using
ADJUST_IBIT(DA, 7)
ADJUST_FBIT(DA, 32)
For vectors, we let the targets define the supported modes. Why do we
want something else for fractional support?
I am not clear about this question. The new modes (FRACT, UFRACT, ACCUM,
and UACCUM) enables GCC to recognize the formats of the underlying values
to perform constant folding (e.g., + - * /).
To use the DA mode for vector, we can use:
VECTOR_MODE (ACCUM, DA, 2);
No, I was trying to make an analogy of how ports explicitly define the
modes their hardware supports, e.g. for arm:
/* Vector modes. */
VECTOR_MODES (INT, 4); /* V4QI V2HI */
VECTOR_MODES (INT, 8); /* V8QI V4HI V2SI */
VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI */
VECTOR_MODES (FLOAT, 8); /* V4HF V2SF */
VECTOR_MODES (FLOAT, 16); /* V8HF V4SF V2DF */
I'm wondering whether it's a good idea to have a lot of pre-defined
fractional modes and types that may or may not match the target
hardware. Not saying it's necessarily wrong; I'm just interested to
hear why you chose to do it this way. (I also just noticed that things
like SHORT_ACCUM_TYPE_SIZE are used but apparently not defined in the
patch - does it actually compile?)
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
