What I want to do is: For a nested branch, if the inner branch contains an
array access operation, we need to determine whether that array access will
cause a trap based on its relationship with other array access operations.
For example:
void func1 (int size)
{
arr1 = new int[size];
arr2 = new int[size];
}
void func2 ()
{
printf (“%d\n”, arr1[x]);
if (a == 10)
if (arr2[x] == 100)
{}
}
Since `printf (“%d\n”, arr1[x]);` must have executed before `if (arr2[x] ==
100)` runs, and both `arr1` and `arr2` are assigned only once with
identical element counts, we can conclude that `arr2[x]` will not trigger a
trap.
My specific approach is:
1) First, traverse every gimple in all functions, recording all array
accesses. Store {{function *, index}, {tree_base(address of the first
element in arr), gimple *stmt}} in the hash_map array_ref. In addition to
array_ref, array_def is also recorded: hash_map{tree_base, size(the number
of elements in arr)}. The tree_base stored in array_def is assigned only
once. This process occurs during the lgen phase.
2) During a second pass through every gimple in all functions, when
encountering an array access in an inner branch, look up {function *,
index} in array_ref. If found, it searches array_def based on tree_base to
check if there exists an array def with the same size. This occurs during
the wpa phase.
Now, the data transfer from the lgen phase to the wpa phase exhibits the
previously described issues. Therefore, I now propose to place the entire
analysis process within the wpa phase, thereby eliminating the need for
data transfer.
Thanks.
ywgrit.
Richard Biener <[email protected]> 于2025年10月14日周二 21:24写道：
> On Tue, Oct 14, 2025 at 2:51 PM ywgrit <[email protected]> wrote:
> >
> >
> >
> > Richard Biener <[email protected]> 于2025年10月14日周二 20:31写道：
> >>
> >> On Tue, Oct 14, 2025 at 2:22 PM ywgrit <[email protected]> wrote:
> >> >
> >> > A program may consist of multiple compilation units, and multiple
> array access operations may exist within the program.
> >> > In SIMPLE_IPA_PASS, I want to check whether the index is consistent
> during two array accesses: During the first pass through all functions,
> traverse all gimples, record each array access operation, and store its
> corresponding {Function *, index} into a hash_set. During the second pass
> through all functions, when encountering the array access operation we wish
> to process, search for {Function *, index} in the hash_set.
> >> > Converting SIMPLE_IPA_PASS to IPA_PASS presents challenges.
> >> > Since Function * is a pointer, direct transfer is meaningless. index
> is an ssa_name, so direct transfer is also impossible. My question is:
> Since the above approach fails, if I encounter an array access operation
> during the wpa phase, how should I determine whether there exists another
> array access operation within the same function that shares the same index?
> >>
> >> You have to split the pass into local analysis pre-WPA which would
> >> need to compute this (while it has access
> >> to the body of the function) a "merge" operation during WPA and a
> >> transform during LTRANS.
> >
> > Is pre-WPA the generate phase?
>
> LGEN, yes.
>
> >> Note
> >> that comparing SSA names itself between functions is meaningless,
> >
> > Is this because ssa_name is bound to the function? i.e.,
> function->gimple_df->ssaname.
>
> Because they are function-local entities, yes.
>
> >> I'm
> >> guessing you want to
> >> compute the array access index based on function parameters?
> >>
> > When I encounter an array access, assuming this array access occurs
> within function func_a, I want to know if there are other array accesses
> with the same index within func_a.
>
> OK, but how does IPA come into play here? You can do this fully
> local, for example
> as said during LGEN.
>
> Richard.
>
> >>
> >> Richard,
> >>
> >> > Thanks.
> >> >
> >> > ywgrit.
> >> >
> >> > Richard Biener <[email protected]> 于2025年10月13日周一 14:42写道：
> >> >>
> >> >> On Sat, Oct 11, 2025 at 10:32 AM ywgrit via Gcc <[email protected]>
> wrote:
> >> >> >
> >> >> > I used the functions stream_write_tree/stream_read_tree in lto. If
> tree
> >> >> > contains ssa_name, then stream_read_tree will generate ice: cfun
> is null in
> >> >> > wpa, so (*SSANAMES (cfun))[ix] will break the program. How to
> write/read
> >> >> > tree contains ssa_name in lto, e.g., wpa phase?
> >> >>
> >> >> You shouldn't - you have to abstract from this somehow as during WPA
> phase
> >> >> a SSA name doesn't make "sense". That said, you have to elaborate a
> bit on
> >> >> what you are trying to do.
> >> >>
> >> >> Richard.
> >> >>
> >> >> > Thanks.
> >> >> >
> >> >> > ywgrit.
> >
> > Thanks.
> >
> > ywgrit.
>
