On Tue, Jul 28, 2020 at 11:02 PM Gary Oblock <g...@amperecomputing.com> wrote:
>
> Richard,
>
> I wasn't aware of release_defs so I'll add that for certain.
>
> When I do a single transformation as part of the transformation pass
> each transformation uses the correct types internally but on the edges
> emits glue code that will be transformed via a dangling type fixup pass.
>
> For example when adding something to a pointer:
>
> _2 = _1 + k
>
> Where _1 & _2 are the old point types I'll
> emit
>
> new_3 = (type_convert)_1
> new_4 = (type_convert)k
> new_5 = new_4 / struct_size // truncating divide
> new_6 = new_3 + new_5
> _2 = (type_convert)_new_6
>
> Note, the casting is done with CONVERT_EXPR
> which is harmless when I create new ssa names
> and set the appropriate operands in
OK, so you're funneling the new "index" values through
the original pointer variable _1? But then I don't see
where the patching up of SSA names and the default
def issue happens.
> new_3 = (type_convert)_1
> _2 = (type_convert)new_6
>
> to
>
> new_3 = new_7
> new_8 = new_6
>
> Now I might actually find via a look up that
> _1 and/or _2 were already mapped to
> new_7 and/or new_8 but that's irrelevant.
>
> To intermix the applications of the transformations and
> the patching of these dangling types seems like I'd
> need to do an insanely ugly recursive walk of each functions
> body.
>
> I'm curious when you mention def-use I'm not aware of
> GCC using def-use chains except at the RTL level.
> Is there a def-use mechanism in GIMPLE because
> in SSA form it's trivial to find the definition of
> a temp variable but non trivial to find the use of
> it. Which I think is a valid reason for fixing up the
> dangling types of temps in a scan.
In GIMPLE SSA we maintain a list of uses for each SSA
def, available via the so called immediate-uses. You
can grep for uses of FOR_EACH_IMM_USE[_FAST]
>
> Note, I'll maintain a mapping like you suggest but not use
> it at transformation application time. Furthermore,
> I'll initialize the mapping with the default defs from
> the DECLs so I won't have to mess with them on the fly.
> Now at the time in the scan when I find uses and defs of
> a dangling type I'd like to simply modify the associated operands
> of the statement. What is the real advantage creating a new
> statement with the correct types? I'll be using SSA_NAME_DEF_STMT
> if the newly created ssa name is on the left hand side. Also, the
> ssa_name it replaces will no longer be referenced by the end of the
> scan pass.
Since you are replacing a[i].b with array_for_b[i] I am wondering
how you do the transform for non-pointer adjustments.
> Note, I do have a escape mechanism in a qualification
> pre-pass to the transformations. It's not intended as
> catch-all for things I don't understand rather it's an
> aid to find possible new cases. However, there are
> legitimate things at this point in time during development
> of this optimization that I need to spot things this way. Later,
> when points to analysis is integrated falling through to
> the default case behavior will likely cause an internal error.
>
> Thanks,
>
> Gary
>
> ________________________________
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Tuesday, July 28, 2020 12:07 AM
> To: Gary Oblock <g...@amperecomputing.com>
> Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
> Subject: Re: 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.]
>
>
> 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..."
