This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] Vectorizer: resolve mix of pointer and object: take 2 part 3





Dorit Naishlos/Haifa/IBM wrote on 23/01/2005 18:41:22:
> (2) The other place where objects and pointers as mixed is within
> the analysis that tries to extract the base, offset, alignment and
> memtag of a data-ref (this is where the code fragment you pointed
> out above is from). In this analysis we always start off with an
> object (array-ref/indirect-ref) and from there on we try to get the
> information we need by peeling off operators recursively, and along
> the way we end up switching between objects and pointers throughout
> the analysis. Indeed this patch does not try to clean away this
> mixture, just make it slightly clearer where we deal with objects
> and where with pointers. I think this could be fixed too. We will
> always have to switch between objects and addresses, but we probably
> could break the code into separate functions, and call one from the
> other when we need to (for example, we may start with an indirect-
> ref '*ptr' (an object) where 'ptr=q+&a[16]'; during the recursion we
> get '&a[16]' (a pointer) and want to analyze it, calling
> get_inner_reference on 'a[16]' (an object)). To be continued,

The analysis of memory reference is now performed in two functions:
vect_object_analysis and vect_address_analysis, which replace
vect_get_base_and_offset and partly vect_get_memtag_and_dr (the extraction
of relevant memory tag is now done in new function vect_get_memtag). We
always start with an object (array-ref/indirect-ref) in
vect_object_analysis. If during object's analysis (with get_inner_reference
or with scalar evolution) we get an address, the function
vect_address_analysis is called. We can recursively call back
vect_object_analysis from vect_address_analysis for ADDR_EXPR (e.g., for
'&a[16]' we'll call object analysis with 'a[16]').

This patch fixes two bugs. The first one occurred when the initial
condition of pointer access is of the form {address + offset1 + offset2}
(e.g.,  vpr benchmark in Spec2000 place.c:1692). We erroneously took only
'offset2' as offset. The second problem was that our analysis stopped
although the base found had evolution in the loop (e.g., eon ggFPoint3.h:59
).

Bootstrapped and tested on ppc-darwin.
O.K. for mainline?

Thanks,
Ira

Changelog entry:

2005-02-10  Ira Rosen  <irar@il.ibm.com>

      * tree-vectorizer.c (vect_get_base_and_offset): Remove.
      (vect_is_simple_iv_evolution): Remove redundant parameter
      and step check.
      (vect_analyze_scalar_cycles): Call vect_is_simple_iv_evolution
      without last parameter.
      (vect_analyze_pointer_ref_access): Get access_fn as parameter.
      Return pointer step. Call vect_is_simple_iv_evolution without
      last parameter. Check only that the step is multiple of size
      type. Remove stmt_vinfo updates.
      (vect_get_memtag_and_dr): Remove.
      (vect_get_memtag): New function.
      (vect_address_analysis): New function.
      (vect_object_analysis): New function.
      (vect_analyze_data_refs): Call vect_object_analysis and
      vect_get_memtag. Update stmt_vinfo fields.


Patch 3:
(See attached file: patch3)

Testcase:
(See attached file: vect-95.c)

Attachment: patch3
Description: Binary data

Attachment: vect-95.c
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]