On Wed, Oct 15, 2025 at 5:51 AM ywgrit <[email protected]> wrote:
>
> 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.
To me it looks like the only relevant IPA analysis is that 'arr1' and
'arr2' are assigned only once (I think IPA reference already
computes this?). That they are allocated to the same size is fully
local analysis, {function *, array, size} with constant size
or a set of 'same' (but unknown) size arrays. Making use of this for
trap analysis (for example by tree-ssa-phiopt.cc:get_non_trapping)
would then only look at the set of array groups that are always
allocated together and of same size. IPA would come into
play when the allocations happen in different functions and IPA
analysis is required to prove that the sizes are equal and that
both allocations actually happened at a particular other program point
(both can be tricky).
Richard.
> 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.
