Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Steven Bosscher stevenb@gmail.com wrote on 02/06/2010 06:13:36 PM: On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com wrote: Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. Another batch of recently introduced target macros instead of target hooks: Not so recently - three years ago. tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_STMT_COST tree-vectorizer.h:#ifndef TARG_VEC_TO_SCALAR_COST tree-vectorizer.h:#ifndef TARG_SCALAR_TO_VEC_COST tree-vectorizer.h:#ifndef TARG_VEC_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_UNALIGNED_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_PERMUTE_COST Could the vectorizer folks please turn these into target hooks? OK, I'll do that. Ira Ciao! Steven
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
On Thu, Jun 3, 2010 at 9:01 AM, Ira Rosen i...@il.ibm.com wrote: Steven Bosscher stevenb@gmail.com wrote on 02/06/2010 06:13:36 PM: On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com wrote: Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. Another batch of recently introduced target macros instead of target hooks: Not so recently - three years ago. tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_STMT_COST tree-vectorizer.h:#ifndef TARG_VEC_TO_SCALAR_COST tree-vectorizer.h:#ifndef TARG_SCALAR_TO_VEC_COST tree-vectorizer.h:#ifndef TARG_VEC_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_UNALIGNED_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_PERMUTE_COST Could the vectorizer folks please turn these into target hooks? Btw, a single cost target hook with an enum argument would be preferred here. Richard. OK, I'll do that. Ira Ciao! Steven
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Richard Guenther richard.guent...@gmail.com wrote on 03/06/2010 02:00:00 PM: tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_STMT_COST tree-vectorizer.h:#ifndef TARG_VEC_TO_SCALAR_COST tree-vectorizer.h:#ifndef TARG_SCALAR_TO_VEC_COST tree-vectorizer.h:#ifndef TARG_VEC_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_UNALIGNED_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_PERMUTE_COST Could the vectorizer folks please turn these into target hooks? Btw, a single cost target hook with an enum argument would be preferred here. Where is the best place to define such enum? Thanks, Ira Richard. OK, I'll do that. Ira Ciao! Steven
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
On Thu, Jun 3, 2010 at 1:14 PM, Ira Rosen i...@il.ibm.com wrote: Richard Guenther richard.guent...@gmail.com wrote on 03/06/2010 02:00:00 PM: tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_STMT_COST tree-vectorizer.h:#ifndef TARG_VEC_TO_SCALAR_COST tree-vectorizer.h:#ifndef TARG_SCALAR_TO_VEC_COST tree-vectorizer.h:#ifndef TARG_VEC_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_UNALIGNED_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_PERMUTE_COST Could the vectorizer folks please turn these into target hooks? Btw, a single cost target hook with an enum argument would be preferred here. Where is the best place to define such enum? target.h already has some of them, so that would be the appropriate place. Richard. Thanks, Ira Richard. OK, I'll do that. Ira Ciao! Steven
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com wrote: Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. Another batch of recently introduced target macros instead of target hooks: tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST tree-vectorizer.h:#ifndef TARG_SCALAR_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_STMT_COST tree-vectorizer.h:#ifndef TARG_VEC_TO_SCALAR_COST tree-vectorizer.h:#ifndef TARG_SCALAR_TO_VEC_COST tree-vectorizer.h:#ifndef TARG_VEC_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_UNALIGNED_LOAD_COST tree-vectorizer.h:#ifndef TARG_VEC_STORE_COST tree-vectorizer.h:#ifndef TARG_VEC_PERMUTE_COST Could the vectorizer folks please turn these into target hooks? Ciao! Steven
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
On 05/26/2010 07:03 PM, Ulrich Weigand wrote: This is the reason why we implemented TARGET_ADDR_SPACE_KEYWORDS as macro (note that all the other address-space related back-end callbacks were already implemented as hooks to begin with). One nice cleanup would be to merge the per-address-space hooks with the generic ones when possible (legitimate_address_p and legitimize_address in particular). I started doing the work last year by hookizing the two relevant target macros, but didn't have time to do the second part. Paolo
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Steven Bosscher wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. However, there are (or at least, used to be) some areas where using hooks is a bit difficult, in particular where interactions between the back-end and one particular front-end (as opposed to common code) are concerned. This is the reason why we implemented TARGET_ADDR_SPACE_KEYWORDS as macro (note that all the other address-space related back-end callbacks were already implemented as hooks to begin with). Kai already said on IRC last night that he can hookize TARGET_ENUM_VA_LIST. Could the folks who introduced TARGET_ADDR_SPACE_KEYWORDS please do the same? I'll have a look. What is the preferred solution these days for hooks between the C front-end and a back-end? targetcm? (Why is there both targetcm and targetm.c ?) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote: Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. For the target address space stuff, it is to the __ea keyword. You don't want a target hook that is called on every identifier, but instead you want a target hook that is called in c_parse_init (in c-parser.c) and init_reswords (in cp/lex.c) to set up the keywords. The target hook would have to duplicate the functionality of all of the setup that c_parse_init and init_reswords do, particularly if they have different semantics. -- Michael Meissner, IBM Until June 14: 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA After June 14: 5 Technology Place Drive, MS 2757, Westford, MA 01886, USA meiss...@linux.vnet.ibm.com
