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
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?
On Wed, May 26, 2010 at 7:16 PM, 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. 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?
Steven Bosscher wrote on 02/06/2010 06:13:36 PM: > > On Wed, May 26, 2010 at 7:16 PM, 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. > > 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 wrote: > > > Steven Bosscher wrote on 02/06/2010 06:13:36 PM: > >> >> On Wed, May 26, 2010 at 7:16 PM, 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. >> >> 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 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 wrote: > > > Richard Guenther 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 >> > >> > > >