Re: Fix problems with tree-sra.c with VIEW_CONVERT_EXPR

[Diego Novillo <dnovillo at redhat dot com>]

On Mon, 2004-06-28 at 16:29, Richard Kenner wrote:
>     Aha, OK.  Assuming that the above is valid GIMPLE (jason?), 
> 
> It has to be.  We discussed why earlier this month.  There's no other
> way to represent it.
> 
OK.

>     I guess we need to make is_sra_candidate_ref and scalarize_modify_expr a
>     bit smarter.
> 
> Actually, this should probably be rewritten to use a tree walk to avoid having
> all the special cases of trying to figure out where the variable might be.
>
Don't do anything until rth is finished overhauling the SRA code.


>     Would this solve your problem?  
> 
> No.
>
Have you checked?

>   It's *not* a candidate ref because the VIEW_CONVERT_EXPR converts it
> into a *different* record!  To give a less confusing case, suppose it were
> 
Irrelevant.  If v2 is scalarizable, then V1 = VIEW_CONVERT_EXPR <V2>
must scalarize the assignment.  Or do you actually want to stop V2 from
being scalarized if it's ever referenced in a VIEW_CONVERT_EXPR node? 
That is a different problem.

> 	<MODIFY_EXPR v1 <REALPART_EXPR <ARRAY_REF <VIEW_CONVERT_EXPR v2> i>>>
> 
> with v2 scalarized and v1 not. We have to notice that buried in there is
> a v2 and we need to copy back all the scalar forms into it since we have
> no idea which of them will be referenced.
> 
We currently don't scalarize arrays, so v2 is not scalarizable here.

>     Oh, and where are we running into this? Is this on the testsuite?
> 
> No.  As I said on my patch, this was compiling the Ada front end.  One of
> the cases (the one with both scalarizable) was in uintp.adb.  I don't
> remember if the other case (the one I found first) was also there or
> was in another file (if the latter, most likely it was cstand.adb).
>
OK.  Thanks.


Diego.