On Tue, Jul 28, 2020 at 4:36 AM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote:
>
> Almost all of the makes sense to.
>
> I'm not sure what a conditionally initialized pointer is.
{
void *p;
if (condition)
p = ...;
if (other condition)
... use p;
will end up with a PHI node after the conditional init with
one PHI argument being the default definition SSA name
for 'p'.
> You mention VAR_DECL but I assume this is for
> completeness and not something I'll run across
> associated with a default def (but then again I don't
> understand notion of a conditionally initialized
> pointer.)
>
> I'm at the moment only dealing with a single malloced
> array of structures of the given type (though multiple types could have this
> property.) I intend to extend this to cover multiple array and static
> allocations but I need to get the easiest case working first. This means no
> side pointers are needed and if and when I need them pointer will get
> transformed into a base and index pair.
>
> I intend to do the creation of new ssa names as a separate pass from the
> gimple transformations. So I will technically be creating for the duration of
> the pass possibly two defs associated with a single gimple statement. Do I
> need to delete the old ssa names
> via some mechanism?
When you remove the old definition do
gsi_remove (&gsi, true); // gsi points at stmt
release_defs (stmt);
note that as far as I understand you need to modify the stmts using
the former pointer (since its now an index), and I would not recommend
to make creation of new SSA names a separate pass, instead create
them when you alter the original definition and maintain a map
between old and new SSA name.
I haven't dug deep enough into your figure how you identify things
to modify (well, I fear you're just scanning for "uses" of the changed
type ...), but in the scheme I think should be implemented you'd
follow the SSA def->use links for both tracking an objects life
as well as for modifying the accesses.
With just scanning for types I am quite sure you'll run into
cases where you discover SSA uses that you did not modify
because you thought that's not necessary (debug stmts!). Of
course you'll simply make more things "type escape points" then.
> By the way this is really helpful information. The only
> other person on the project, Erick, is a continent away
> and has about as much experience with gimple as
> me but a whole heck lot less compiler experience.
>
> Thanks,
>
> Gary
>
> ________________________________
> From: Gcc <gcc-boun...@gcc.gnu.org> on behalf of gcc-requ...@gcc.gnu.org
> <gcc-requ...@gcc.gnu.org>
> Sent: Monday, July 27, 2020 1:33 AM
> To: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
> Subject: Gcc Digest, Vol 5, Issue 52
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
> be mindful of safe email handling and proprietary information protection
> practices.]
>
>
> Send Gcc mailing list submissions to
> gcc@gcc.gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://gcc.gnu.org/mailman/listinfo/gcc
> or, via email, send a message with subject or body 'help' to
> gcc-requ...@gcc.gnu.org
>
> You can reach the person managing the list at
> gcc-ow...@gcc.gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gcc digest..."
