RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood <carlo@alinoe.com>]

I worked out several ways to achieve said goal of fixing the
debug info of calls and inlining,
(see http://gcc.gnu.org/ml/gcc/2003-09/msg00942.html)
but in all cases there needs to be a location_t assigned to
every CALL_EXPR.

The most robust and simplist solution is to add a
location_t to tree_exp.  When I mentioned on IRC that
I had solved it this way, there was objection about
memory usage.  But tree-ssa (3.5) even adds a
location_t to tree_common!  Then why not do the same
for 3.4 already so I can solve the problem at hand?

A suggestion was to use expr wfl, but that is impractical:
there are too many places where an expressions type is directly
compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
all of those places would have to be changed to also check for
a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
unwrap the call expr in order to subsequentially be able to
process it.  I heared that this is the way that tree-ssa has
attempted to add locations at first (using a macro STRIP_WFL),
but also then was decided that it was undoable.

Imho, the conclusion is, looking at how this will be done
more generally in 3.5, that we should simply solve this for
3.4 in the same way (memory consumption wise) and
- adding an addition pointer or integer to tree_exp, until the
merge with tree-ssa 3.5.  This should be acceptable.

If people think that that uses too much memory nevertheless,
then please explain how else it is possible to add a location_t
to a CALL_EXPR.  Or just tell me what WILL be approved in terms
of memory usage. 
- Add a complete tree_common + location_t to every
CALL_EXPR?  Then I could add another operand to call expressions.
- Or only a single location_t per CALL_EXPR (the very minimum of
memory usage).  That is possible but then I will have to make
some changes to how the ggc_* works now (I'd dynamically add a
location_t *behind* the operand[]).

On Mon, Sep 22, 2003 at 02:17:10AM +0200, Carlo Wood wrote:
> Proposal for new behaviour
> --------------------------
> 
> My proposal for a new behaviour is that the above assembly code
> would contain the following line numbers:
> 
> _Z1fv:
> .LFB4:
>         .file 1 "troep.c"
>         .loc 1 20 0			// Prologue of f() at line 20
>         pushl   %ebp
> .LCFI0:
>         movl    %esp, %ebp
> .LCFI1:
>         subl    $56, %esp
> .LCFI2:
> .LBB2:
> .LBB3:
>         .loc 1 21 0			// Line 21
>         call    _Z1hv			// Call that is actually done at line 21
>         movl    %eax, -12(%ebp)
> 	.loc 1 12 0			// Line 12
>         call    _Z1hv			// Call that is actually done at line 12
>         movl    %eax, -16(%ebp)
> .LBB4:
>         .loc 1 6 0			// Line 6 for inlined i()
>         movl    $12345, -24(%ebp)	// Assignment to v.
> 	.loc 1 13			// Line 13
>         call    _Z1hv			// Call that is actually done at line 13
[...]

-- 
Carlo Wood <carlo@alinoe.com>