This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ada bootstrap failure due to loop optimization andbuiltin_stack_alloc


On Thu, 2004-07-29 at 11:24, Zdenek Dvorak wrote:
> 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 &.
> > > 
> > Then it is broken.  In GIMPLE ADDR_EXPR is never a reference to memory.
> 
> unfortunately this is not quite true at the moment.  An array x that is
> allocated via stack_alloc builtin is actually used in two meanings:
> 
I was too hasty.  ADDR_EXPR could 
> 1) As x[whatever], it corresponds to the contents of the array x.
> 2) As &x, it corresponds to the address of the array x, which is also
>    variable (since single builtin_stack_alloc may be run several times
>    and assign different addresses to it).
> 
> While we correctly maintain virtual operands for 1), we do not do it
> for 2), which causes the Ada bootstrap problem.
> 
But why should we maintain virtual operands for it?  There are none.  If
the address of 'x' is not invariant, then we cannot lift it out of the
loop.

Send me the code again?  

Kenner, I am growing very tired of your reluctance to use a proper
mailer.  Given the high volume of mail on the gcc lists, it is almost
impossible to keep track of discussions that you take part of.  Please
upgrade your mail program!

> In the mail you responded to I have outlined two possible approaches to
> fixing this; I have both basically done, so I am just waiting on what
> will people consider better (or whether someone will not have a better
> idea how to solve the problem).
> 
Perhaps #1.  But I think neither, the address of that variable is not
invariant, so it shouldn't be lifted out of the loop.  But I lost track
of the original test case, so I'm not convinced I'm making any sense.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]