Pointer addition/subtraction tree node
As part of adding a new pass to GCC I am intercepting addition to and subtraction from pointers. These are represented by PLUS_EXPR and MINUS_EXPR tree nodes. I need to be able to find out which of the node's two operands is the actual pointer and which is the integer that has been added to it. Subtraction is not a problem. The real pointer always seems to be the first operand (makes sense). If the integer is a constant (e.g. p = p + 4) I can catch it by checking the type: TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST But in other cases (e.g. p = p + i) I can't do this by looking at the type as they both have the same type as the result pointer. Is there another way to find out which is which? Thanks. Alex
RE: Pointer addition/subtraction tree node
Code of the form int[10] a; int* p = a; int* q = a; int i = 3; p = q + i; is transformed into int * D.900; unsigned int D.899; unsigned int i.0; : i = 3; p = &a; q = &a; i.0 = (unsigned int) i; D.899 = i.0 * 4; D.900 = (int *) D.899; p = D.900 + q; by the time it reaches the fixupcfg pass. It has been suggested to me that a solution might be to trace back through the tree to find which of the operands is derived from a non-pointer variable. I am new to GCC development. How might I go about doing this? Another approach I tried was to detect which of the operands was a compiler intermediate (my theory being that this would always be the non-pointer operand) by using DECL_ARTIFICIAL (TREE_OPERAND (t, 0)) but this breaks if tried on an operand that is not a VAR_DECL. I don't think my theory is sounds but if it is, is there a way to get this to work? Thanks. Alex. > -Original Message- > From: Andrew Pinski [mailto:[EMAIL PROTECTED] > Sent: 19 March 2007 00:47 > To: Alexander Lamaison > Cc: gcc@gcc.gnu.org > Subject: Re: Pointer addition/subtraction tree node > > On 3/18/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote: > > As part of adding a new pass to GCC I am intercepting addition to and > > subtraction from pointers. These are represented by PLUS_EXPR and > > MINUS_EXPR tree nodes. I need to be able to find out which of the > node's > > two operands is the actual pointer and which is the integer that has > been > > added to it. > > > > Is there another way to find out which is which? > > Not right now, I have been working on a new representation of pointer > arithmetic for the tree level. The basic implementation is already > done, see the pointer_plus branch. > > Thanks, > Andrew Pinski
RE: Pointer addition/subtraction tree node
> -Original Message- > From: Andrew Pinski [mailto:[EMAIL PROTECTED] > Sent: 19 March 2007 00:47 > To: Alexander Lamaison > Cc: gcc@gcc.gnu.org > Subject: Re: Pointer addition/subtraction tree node > > On 3/18/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote: > > As part of adding a new pass to GCC I am intercepting addition to and > > subtraction from pointers. These are represented by PLUS_EXPR and > > MINUS_EXPR tree nodes. I need to be able to find out which of the > node's > > two operands is the actual pointer and which is the integer that has > been > > added to it. > > > > Is there another way to find out which is which? > > Not right now, I have been working on a new representation of pointer > arithmetic for the tree level. The basic implementation is already > done, see the pointer_plus branch. > > Thanks, > Andrew Pinski Apologies for top-posting before: Code of the form int[10] a; int* p = a; int* q = a; int i = 3; p = q + i; is transformed into int * D.900; unsigned int D.899; unsigned int i.0; : i = 3; p = &a; q = &a; i.0 = (unsigned int) i; D.899 = i.0 * 4; D.900 = (int *) D.899; p = D.900 + q; by the time it reaches the fixupcfg pass. It has been suggested to me that a solution might be to trace back through the tree to find which of the operands is derived from a non-pointer variable. I am new to GCC development. How might I go about doing this? Another approach I tried was to detect which of the operands was a compiler intermediate (my theory being that this would always be the non-pointer operand) by using DECL_ARTIFICIAL (TREE_OPERAND (t, 0)) but this breaks if tried on an operand that is not a VAR_DECL. I don't think my theory is sounds but if it is, is there a way to get this to work? Thanks. Alex.
Using SSA
I am adding a new optimisation pass to GCC and I have found that I probably need to make use of SSA's definition-finding. The problem I am having is that the trees I am working on don't seem to be in SSA form (i.e. not SSA_NAME nodes). I have looked endlessly and can't find any documentation on the basics of getting set up to use SSA. I've tried looking at existing optimisation passes but I can't find anything that they do in common in the way of set-up. The tree_opt_pass for my pass has PROP_ssa set in the properties_required field. Is this all I need to do? Any help is greatly appreciated. Alex
RE: Using SSA
> > The tree_opt_pass for my pass has PROP_ssa set in the > properties_required > > field. Is this all I need to do? > > You need to put your pass after pass_build_ssa. Setting PROP_ssa does > not build SSA itself, but it will cause an assertion failure if the > pass is run while SSA is (not yet) available. > > Paolo I think (if I'm correctly interpreting the list in passes.c) it is. It's right after pass_warn_function_noreturn, just before pass_mudflap_2. Is this right? I don't get any assertion about SSA not being available. Thanks. Alex
RE: Using SSA
> > I think (if I'm correctly interpreting the list in passes.c) it is. > It's > > right after pass_warn_function_noreturn, just before pass_mudflap_2. > Is > > this right? I don't get any assertion about SSA not being available. > > In this case, it is also after pass_del_ssa, which means SSA has > already > been destroyed. Oh, ok. Thanks! I had assumed the mudflap passes would have SSA enabled as the 'Tree-SSA passes' section of the GCC internal manual listed them: http://gcc.gnu.org/onlinedocs/gccint/Tree_002dSSA-passes.html#Tree_002dSSA-p asses. Thanks. Alex.
RE: Progress on GCC plugins ?
Diego Novillo wrote: > Richard Kenner wrote: > > > I don't see that. Why is it that much harder to link in with GCC > than doing > > it as a plugin? > > Limited time and steep learning curves. Typically, researchers are > interested in rapid-prototyping to keep the paper mill going. Plug-ins > offers a simple method for avoiding the latencies of repeated bootstrap > cycles. > > Several projects will survive the initial prototyping stages and become > techniques we can apply in industrial settings. We want to attract > that. Plus we want to attract the grad students that did the research > and graduate with a favourable attitude towards using GCC in their > future career. As a research student who spent 6 months working on an improvement to GCC, I agree with all of Diego's remarks. Out of the 6 months, 4 were spent learning the GCC internals and fighting the GCC build process, 1 was spent writing up leaving 1 month of actual productive research. While not all of this would be solved by a plugin system (a lot was down to documentation) it would have significantly increased the amount of time I had to make useful contributions. I fully understand that this can seems strange to people who know GCC like the back of their hand, but to a newcomer it is a huge task just to write a single useful line of code. I'm sure many give up before ever reaching that point. Alex Lamaison Imperial College London
Re: Progress on GCC plugins ?
Quoting Martin Jambor <[EMAIL PROTECTED]>: So as far as attracting new programmers, researchers and inexperienced students in particular is concerned, I think that effort that implementing plugins would take would be much better spent on keeping documentation up to date, possibly improving it (hey, Alexander, what were your problems, someone might answer them on Wiki for others!) and, in particular, staying as friendly and forgiving community as you are (especially on IRC anyway :-). I certainly agree with this! The same effort spent on documentation rather than on a plugin system would, imho, give greater value. But, as there seems to be a willingness to work on plugins in contrast to the willingness to document, I am supporting progress wherever it is on offer. The project is over and eventually I solved the problems through sweat and tears. I have the solutions scribbled down somewhere and eventually I mean to put the up on the web somewhere to save others the same pain.
