This is the mail archive of the gcc@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] | |
The attached patch implements (partially) the first part of proposed work: exporting and verification of data dependence information.
The implementation follows the outline presented in my initial message on the project, here: http://gcc.gnu.org/ml/gcc/2007-03/msg00900.html . Data references and data dependency relations obtained via compute_dependencies_for_loop are copied into containing struct (which is a member of struct function). This containing struct is marked GTY((skip)), because its lifetime and lifetime of its components is known (from the moment of export until destruction late in the RTL pipeline). However, I need to preserve trees that are referenced in the exported datarefs (to be able to bind MEMs to datarefs later), so I need to put them into a GC-visible array. For now that array is global. Can it be done better?
MEMs are bound to datarefs by means of saving original trees for MEMs during expand. This is a large part of the attached patch with changes to emit-rtl.[ch], which adds new field to struct mem_attrs (mem_orig_expr), initializes it and propagates through various RTL transformations. Notice that it has stricter hashing (as compared to orig_expr part of the same struct), so it will reduce sharing of mem_attrs (and also increase size of the struct, obviously). Can it be a problem? Please also note that this patch is a part of aliasing information exporting patch by Dmitry Melnik, which available now in alias-export branch.
After original tree is found, a corresponding dataref is looked up in exported info. I guess I will need here hashtabs for fast lookup (also for searching ddrs for pairs of datarefs), am I right?
The only place that required patching so far wrt. exporting was iv-opts pass (we need to rewrite TARGET_MEM_REFs to their respective TMR_ORIGINALs, because that's what MEM_ORIG_EXPR will provide binding to later). However, the issue of basic block duplication is not addressed yet in this patch, I will be looking into it shortly.
The verification routines walk all loops and memory references in function, and provide counters of references with/without relevant exported dataref, and also count number of exported ddrs. They are run after every pass, both GIMPLE and RTL. On GIMLPE, verifier looks into REFERENCE_CLASS_P trees being LHSs and RHSs of MODIFY_STMTs (as compute_dependencies_for_loop does), on RTL simply all MEMs are visited. However, I just noticed that 'optimized' dump may contain D.2108 = (short unsigned int) shortsum + (short unsigned int) MEM[symbol: data_ch, index: (unsigned int) i]; which is not verifier expects.
The verifier also frequently breaks on passes that create unreachable basic blocks (because dominator analysis called from flow_loops_find asserts there are none). For now I just place delete_unreachable_blocks in such passes, is that ok?
I'm proceeding with testing on small examples (tree-vectorizer testsuite provides plenty :) ).
-- Alexander Monakov
Attachment:
export-ddg.patch.txt
Description: Text document
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |