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]

[GSoC: DDG export][RFC] Current status


Hello,

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 :) ).

Thanks in advance for comments

--
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]