This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: [GUPC] UPC-related front-end changes


On Fri, 1 Jul 2011, Gary Funck wrote:

> * Most of the #ifdef conditionals have been removed.  Some target macros
> have been defined and documented in tm.texi.  We still have some questions

For each target macro, what is the justification requiring it to be a 
macro rather than a hook documented in target.def with just an @hook line 
in tm.texi.in?  The justification should be one of:

* Macro is used in a case label, defining the values of an enum or some 
other such context that requires a constant value and the code would be 
substantially obfuscated by changing it to avoid this.  (Normally "if" 
statements are preferred to #if conditionals.  Simple use in #if is not 
sufficient justification for a target macro, you need to explain why it is 
necessary to use a preprocessor conditional - for example, if the #if is 
there to control values in an enum.)

* Macro is very closely related to an existing set of macros, such that it 
does not make sense for some members of the set to be hooks while others 
are macros.

* Benchmarking with provided figures has shown significant performance 
regressions from use of a hook.

I looked at the first of the documented macros, and it doesn't seem to be 
a target macro at all, being defined by configure rather than in tm.h.  
Configure-defined macros don't go in tm.texi.  But any that are really 
target macros need such a justification, and it's still preferable to 
define configure-defined macros to 1 or 0 (rather than defined or 
undefined) and test them in "if" statements not #if.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]