Fix problems with tree-sra.c with VIEW_CONVERT_EXPR

Richard Kenner kenner@vlsi1.ultra.nyu.edu
Mon Jun 28 21:04:00 GMT 2004


    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.

    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.
Each time we miss one, we generate wrong code because we leave out the
copy-in or copy-out.

    Would this solve your problem?  

No.  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

	<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.

    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).



More information about the Gcc-patches mailing list