Re: Ada bootstrap failure due to loop optimization and builtin_stack_alloc

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

>     this sounds weird.  
> 
> It's a wierd builtin!
> 
>     What are the virtual operands on __builtin_stack_alloc and the
>     assignment statements?
>
> There are none on the assignment.

hmm....  right.  The problem is that &argv behaves in a really weird way --
it really refers to memory, unlike any other occurence of &.

In the very first incarnation of the patch for making the stack
allocation for variable sized objects explicit
(http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01369.html)
I solved the problem by rewriting every use of the object by a pointer
to it, i.e. the code in question would look like

argv_ptr = _builtin_stack_alloc (iftmp.293_316);
...
argv.103_273 = (character[...] *) argv_ptr;

This would work, but of course it breaks debugging.  This is why the
idea was changed to what we have now (and I somehow managed to persuade
myself that it should work ... it in fact did until we later noticed
that & operator does not refer to memory, so there is no reason to add
virtual operands for it).

I see two ways how to fix the problem:

1) We could use the original idea of making the pointers explicit.
   This is a clean way, since it precisely expresses what is happening,
   but we would need to somehow live with the fact that it makes
   debugging more difficult (or find out some way how to make debugging
   info reflect it; I have no idea whether this is possible).
2) We can make the semantics of & operand on VLA object different, in
   particular record a VUSE for it.  This is a bit ugly, since it may
   happen that some other optimizations rely on how ADDR_EXPRs behave
   and the different behavior for VLAs could cause other problems.
   On the other hand it is by far less intrusive change (addition of
   two lines to tree-ssa-operands.c).

What is the preferred way?  Or is there some other option I don't see?

Zdenek

> Here's the builtin call:
> 
>   #   FRAME.267_413 = V_MAY_DEF <FRAME.267_397>;
>   #   opt__stack_checking_enabled_149 = V_MAY_DEF <opt__stack_checking_enabled_92>;
>   #   opt__output_file_name_present_150 = V_MAY_DEF <opt__output_file_name_present_93>;
>   #   T.104_414 = V_MAY_DEF <T.104_398>;
>   #   T.108_415 = V_MAY_DEF <T.108_399>;
>   #   T.110_416 = V_MAY_DEF <T.110_400>;
>   #   T.113_417 = V_MAY_DEF <T.113_401>;
>   #   T.115_418 = V_MAY_DEF <T.115_402>;
>   #   T.117_419 = V_MAY_DEF <T.117_403>;
>   #   T.120_420 = V_MAY_DEF <T.120_404>;
>   #   opt__no_stdinc_151 = V_MAY_DEF <opt__no_stdinc_94>;
>   #   T.124_421 = V_MAY_DEF <T.124_405>;
>   #   opt__no_stdlib_152 = V_MAY_DEF <opt__no_stdlib_95>;
>   #   T.128_422 = V_MAY_DEF <T.128_406>;
>   #   T.131_423 = V_MAY_DEF <T.131_407>;
>   #   T.133_424 = V_MAY_DEF <T.133_408>;
>   #   TMT.288_425 = V_MAY_DEF <TMT.288_409>;
>   #   TMT.289_426 = V_MAY_DEF <TMT.289_410>;
>   #   TMT.290_427 = V_MAY_DEF <TMT.290_411>;
>   #   argv_428 = V_MAY_DEF <argv_412>;
>   __builtin_stack_alloc (&argv, iftmp.293_316);