RE: Fixed-point branch?
Bernd Schmidt wrote:
I attached a diff file for 14 files of the new structures
and documents. You and other maintainers are welcome to
check it. Thanks a lot!
Note: 14 files are =
genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
tree.c rtl.def rtl.h rtl.c fixed-value.h fixed-value.c
doc/extend.texi doc/rtl.texi doc/c-tree.texi doc/md.texi
Random comments..
+ unsigned saturating_flag : 1; /* FIXME. This new flag
increases the size of
+ tree_common by a full word. */
Sounds undesirable. We need to look hard for a way to avoid this.
Yes, we can get one of 24 spare bits for this flag. We just fixed this
issue last week.
+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);
+int
+fixed_zerop (tree expr)
+{
+ return TREE_CODE (expr) == FIXED_CST
+ double_int_zero_p (TREE_FIXED_CST (expr).data);
+}
Formatting - this needs parentheses. Elsewhere too.
Ok.
+static tree
+make_or_reuse_fract_type (unsigned size, int unsignedp, int satp)
Comments before functions.
Ok. Thanks!
Regards,
Chao-ying
Re: Fixed-point branch?
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
RE: Fixed-point branch?
Bernd Schmidt 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?) Ok. I got it. Maybe we treat fixed-point modes as the first class modes like other scalar modes (integer, floating, etc.), so we pre-define them. We can argue that how about making machine modes (ex: floating-point, decimal floating-point) not pre-defined, similar to vector modes. I think, the default fixed-point formats are the efficient ones for 32-bit/64-bit processors (with or without hardware supports). One of the goals for the fixed-point extension is that all targets in GCC will enable the extension, so efficient formats may be set by default. We have all FRACT and ACCUM sizes in defaults.h. Thanks! #ifndef SHORT_FRACT_TYPE_SIZE #define SHORT_FRACT_TYPE_SIZE BITS_PER_UNIT #endif #ifndef FRACT_TYPE_SIZE #define FRACT_TYPE_SIZE (BITS_PER_UNIT * 2) #endif #ifndef LONG_FRACT_TYPE_SIZE #define LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 4) #endif #ifndef LONG_LONG_FRACT_TYPE_SIZE #define LONG_LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 8) #endif #ifndef SHORT_ACCUM_TYPE_SIZE #define SHORT_ACCUM_TYPE_SIZE (SHORT_FRACT_TYPE_SIZE * 2) #endif #ifndef ACCUM_TYPE_SIZE #define ACCUM_TYPE_SIZE (FRACT_TYPE_SIZE * 2) #endif #ifndef LONG_ACCUM_TYPE_SIZE #define LONG_ACCUM_TYPE_SIZE (LONG_FRACT_TYPE_SIZE * 2) #endif #ifndef LONG_LONG_ACCUM_TYPE_SIZE #define LONG_LONG_ACCUM_TYPE_SIZE (LONG_LONG_FRACT_TYPE_SIZE * 2) #endif Regards, Chao-ying
RE: Fixed-point branch?
Mark Mitchell wrote: I attached a diff file for 14 files of the new structures and documents. You and other maintainers are welcome to check it. Thanks a lot! Thank you for posting this. Things about which I am clueless: What is the difference between a _Fract type and an _Accum type? I'm gathering that _Fract types have no integer part, i.e., they always represent a number between (-1,1), whereas _Accum types contain both an integer and a fractional part. Is there any other difference? No other differences. For _Fract and _Accum, there are signed and unsigned types. The unsigned _Fract and _Accum types are always = 0. Substantive issues: + unsigned saturating_flag : 1; /* FIXME. This new flag increases the size of +tree_common by a full word. */ We need to fix that, if it's true. Grab a bit out of tree_base::spare, if need be. Yes. Will get one spare bit for saturating_flag. + /* Fixed-point types. */ + if (targetm.fixed_point_supported_p ()) I thought there was an emulation library for fixed-point operations? So, why would this be supported only on some targets? Is there a harm in supporting it everywhere? If there is, should it be enabled per-target, or via a configure-time option? Right now, the fixed-point support is a configure-time option. Each target can decide to support it or not. I think there is no harm to enable for every target. But, each target needs to modify tm.h tm.c tm-modes.def to set or change some target macros. I don't see any constant-folding code for fixed-point; is there no need for that? Is it somewhere else in the codebase? I will post a diff file that has everything including constant-folding code soon. Stylistic points: Every function needs a comment saying what it does, what every argument is, and what the return value is. You have some new functions that are missing comments. Ok. Will fix it. + fixed-point - real, Please write as real to fixed point to avoid ambiguity with the errors. Ok. Will fix it. +DEF_RTL_EXPR(FIXED_ALL, fixed_all, e, RTX_UNARY) Why FIXED_ALL? That doesn't seem mnemonic. It's hard to pick up a name. Maybe we will change it to the following as Nigel suggested. /* Conversions involving fractional fixed point types without saturation, including: fractional to fractional (of different precision), signed integer to fractional, fractional to signed integer, floating point to fractional, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, fract_convert, e, RTX_UNARY) + sat_short_fract_type_node = make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE); + sat_fract_type_node = make_sat_signed_fract_type (FRACT_TYPE_SIZE); + sat_long_fract_type_node = make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE); + sat_long_long_fract_type_node = make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE); Can we macroize some of this goo? There are several places in the patch where you have very long sequences of types, modes, etc. I would hope that by naming things consistently, we might be able to compact this a lot, and reduce the chance that we've got something wrong in just one place. Like: #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ set_##WIDTH_##KIND_type_node = make_##SAT_... and then: #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ MAKE_FIXED_TYPE_NODE(_short, KIND); \ MAKE_FIXED_TYPE_NODE(_, KIND); \ MAKE_FIXED_TYPE_NODE(_long, KIND); \ MAKE_FIXED_TYPE_NODE(_long_long, KIND); and then: MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); etc. That's not right, but you get the idea. :-) Ok. We will try to shorten C code. Thanks! Regards, Chao-ying
Re: Fixed-point branch?
Fu, Chao-Ying wrote: Right now, the fixed-point support is a configure-time option. Each target can decide to support it or not. I think there is no harm to enable for every target. But, each target needs to modify tm.h tm.c tm-modes.def to set or change some target macros. I would suggest making it a configure-time option, and eliminating the target hook. Then, people can turn it on when they want. If they try to turn it on for a target that doesn't have the necessary support, the compiler will break, and they can fix it. It's hard to pick up a name. Maybe we will change it to the following as Nigel suggested. /* Conversions involving fractional fixed point types without saturation, including: fractional to fractional (of different precision), signed integer to fractional, fractional to signed integer, floating point to fractional, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, fract_convert, e, RTX_UNARY) Yes, I think that's better. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Fu, Chao-Ying wrote: I attached a diff file for 14 files of the new structures and documents. You and other maintainers are welcome to check it. Thanks a lot! Thank you for posting this. Things about which I am clueless: What is the difference between a _Fract type and an _Accum type? I'm gathering that _Fract types have no integer part, i.e., they always represent a number between (-1,1), whereas _Accum types contain both an integer and a fractional part. Is there any other difference? Substantive issues: + unsigned saturating_flag : 1; /* FIXME. This new flag increases the size of + tree_common by a full word. */ We need to fix that, if it's true. Grab a bit out of tree_base::spare, if need be. + /* Fixed-point types. */ + if (targetm.fixed_point_supported_p ()) I thought there was an emulation library for fixed-point operations? So, why would this be supported only on some targets? Is there a harm in supporting it everywhere? If there is, should it be enabled per-target, or via a configure-time option? I don't see any constant-folding code for fixed-point; is there no need for that? Is it somewhere else in the codebase? Stylistic points: Every function needs a comment saying what it does, what every argument is, and what the return value is. You have some new functions that are missing comments. + fixed-point - real, Please write as real to fixed point to avoid ambiguity with the errors. +DEF_RTL_EXPR(FIXED_ALL, fixed_all, e, RTX_UNARY) Why FIXED_ALL? That doesn't seem mnemonic. + sat_short_fract_type_node = make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE); + sat_fract_type_node = make_sat_signed_fract_type (FRACT_TYPE_SIZE); + sat_long_fract_type_node = make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE); + sat_long_long_fract_type_node = make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE); Can we macroize some of this goo? There are several places in the patch where you have very long sequences of types, modes, etc. I would hope that by naming things consistently, we might be able to compact this a lot, and reduce the chance that we've got something wrong in just one place. Like: #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ set_##WIDTH_##KIND_type_node = make_##SAT_... and then: #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ MAKE_FIXED_TYPE_NODE(_short, KIND); \ MAKE_FIXED_TYPE_NODE(_, KIND); \ MAKE_FIXED_TYPE_NODE(_long, KIND); \ MAKE_FIXED_TYPE_NODE(_long_long, KIND); and then: MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); etc. That's not right, but you get the idea. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Fu, Chao-Ying wrote: 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Maybe you could first check if new machine modes, new TREE structures (a saturating bit, fixed-point type, fixed-point constant), new RTL structures (fixed-point constant and operators) are ok. I had not realized that there were so many changes outside of the C front end. I think that it does indeed make sense to have someone look at some of that stuff. I will be happy to take a look. Will you please send me a patch (and CC the list) for the middle-end changes? It doesn't have to apply to mainline cleanly, but that will give me -- and people who know better than I! -- a chance to look over the infrastructure changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Fixed-point branch?
-Original Message- From: Mark Mitchell [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 9:05 AM To: Joseph S. Myers Cc: Fu, Chao-Ying; Richard Henderson; GCC Subject: Re: Fixed-point branch? Joseph S. Myers wrote: I haven't examined it. When the branch maintainers consider it ready to merge I hope a proposal along the lines of the DFP one http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html will be posted (see also subsequent discussion in that thread, and on the submitted patches). I would like to avoid the situation in which Chao-Ying et. al. work hard to come up with a plan, factor the patches, etc., and then we decide that the code is not going to be ready for 4.3. I had originally pushed this work back to 4.4, but as 4.3's been delayed, perhaps there's an opportunity for it in 4.3. If, however, the work isn't ready, then I'd rather not take up a lot of Chao-Ying's time now; instead, we can just wait for 4.4 to get closer. At the same time, of course, there's not much point in you investing in looking at the branch if Chao-Ying doesn't think it's ready. So, let's do this: 1. Chao-Ying, would you please work on any remaining issues that you feel need resolution. Then, post your merge plan, ala DFP. Yes. We will work on remaining issues and post our merge plan. 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Maybe you could first check if new machine modes, new TREE structures (a saturating bit, fixed-point type, fixed-point constant), new RTL structures (fixed-point constant and operators) are ok. Thanks a lot! Regards, Chao-ying
Re: Fixed-point branch?
On Mon, 28 May 2007, Mark Mitchell wrote: Joseph, Richard -- As C maintainers, have either of you looked at Chao-Ying's fixed-point branch? I haven't examined it. When the branch maintainers consider it ready to merge I hope a proposal along the lines of the DFP one http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html will be posted (see also subsequent discussion in that thread, and on the submitted patches). (a) whether implementing N1169 is likely to be dangerous, in the sense that the committee might eventually adopt a substantially conflicting version of the specification, N1169 is the current version, with various defects addressed relative to the published TR18037 but has not yet been published as a new revision of the TR because of ISO bureaucracy. (To quote the draft London minutes, TR 18037 (embedded) has had all defects addressed. SC 22 secretariat is requiring a NWI ballot for revising this, which is against the JTC 1 procedures.) If any of this is included in (an Annex to) C1x, it remains to be seen if the committee will follow the expressed principle of standardising existing practice without changing it incompatibly. If it just moves from being a TR to being an IS, I wouldn't expect problems with changes there. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Fixed-point branch?
Joseph S. Myers wrote: I haven't examined it. When the branch maintainers consider it ready to merge I hope a proposal along the lines of the DFP one http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html will be posted (see also subsequent discussion in that thread, and on the submitted patches). I would like to avoid the situation in which Chao-Ying et. al. work hard to come up with a plan, factor the patches, etc., and then we decide that the code is not going to be ready for 4.3. I had originally pushed this work back to 4.4, but as 4.3's been delayed, perhaps there's an opportunity for it in 4.3. If, however, the work isn't ready, then I'd rather not take up a lot of Chao-Ying's time now; instead, we can just wait for 4.4 to get closer. At the same time, of course, there's not much point in you investing in looking at the branch if Chao-Ying doesn't think it's ready. So, let's do this: 1. Chao-Ying, would you please work on any remaining issues that you feel need resolution. Then, post your merge plan, ala DFP. 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Mark Mitchell wrote: Chao-Ying, I'm also interested in whether or not these changes have any impact on C++. With your changes, does GNU C++ now accept any fixed-point constructs? Chao-ying's on vacation this week. AFAIK Chao-ying's code does nothing explicit to support, or not support, C++. The front-end code was based on the Decimal floating point extension, so should currently behave in a similar fashion to that with regards C++. If so, are you aware of any effort to standardize any of this functionality in C++? Annex F (page 96) of the N1169 spec (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf) does give some guidelines for C++ usage, but only a very hand-wavy couple of paragraphs. I guess we can ask the committee members if there is any work going on in this area. (I think that my preference, in the short term, would be to disable this functionality in C++ -- although, of course, we will eventually want to turn it on so that GNU C++ is as much as possible a superset of GNU C.) OK Nigel
