Thanks, I will try the interface functions in IPA reference. Now I just test whether the objects of two component-refs are same, and this is down by const-prop, which convert "this->" to "object.".
Richard Biener <[email protected]> 于2025年10月15日周三 21:07写道： > 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. >
