Absence of canonical form for N_array elements cripples CWLE
Bugzilla Link | 871 |
Created on | Sep 08, 2011 16:41 |
Version | svn |
OS | Linux |
Architecture | PC |
Attachments | crud.sac |
Extended Description
Created an attachment (id=818) source code to reproduce failure The attached code fails to remove a copy-WL, when compiled with: sac2c -bopt crud.sac -v0 -DEXTRA >crud The -DEXTRA introduces a X= toi(X); which turns into a copy-WL, because X is already int[.]. This is with Build #rev 17603:MODIFIED, heavily modified by rbe in CWLE shape comparators. The problem boils down to this: One of the criteria that CWLE uses to detect a copy-WL is to compare the BOUND2 of the consumer-WL with the shape of the producer (which may be a WL or not...). In this case, we have: _flat_0 = 50; GENERATOR_BOUND2( cwl) = [ _flat_0, siz ]; _flat_1 = [ 50, siz ]; shape(mat) = _flat_1; This causes PM to fail, because it is unable to compare the two N_array nodes. Although they are identical in value, they differ in structure. The problem appears to be a failure to have a canonical representation of an N_array, due to different treatment of AKV elements in an N_array. PROPOSAL 1: Define and implement a canonical representation of N_array nodes. PROPOSAL 2: Within optimization cycles, all N_array nodes elements will be N_id nodes. I.e., ARRAY_AELEMS are all flattened. In the above, _flat_1 would be illegal; we would expect to see [ _flat_0, siz]; I have several reasons for proposing this behavior: 1. Having a canonical representation ensures that PM can match N_array nodes easily and reliably. 2. It also ensures that CSE, VP, etc., will work as expected. 3. Within the optimizers, we observe several sorts of operations on N_array nodes, particularly those that are shape vectors, generator bounds, etc. These are typified by: narray1 ++ narray2; take( [n], narray); drop( [n], narray); Having ALL elements as N_id nodes allows these operations, and similar ones, to act simply and consistently. In contrast, any representation that attempts to unflatten array elements, whether in whole or in part, makes a huge amount of work for the optimizers: - A change in element type MUST force a review of all of its references. E.g., if _flat_0 started out as AKS, [say from _flat_0 = ( 3 - 2)], and became AKV later on, then SOME piece of code has to unflatten all N_array references to _flat_0. - If flattening/unflattening is based on an analysis of all array elements, rather than independently on each element, then SOME piece of code must review the N_arrays resulting from catenate, take, drop, etc. Having said all this, I note that _flat_1 appears very early in compilation (by -bewl), and is due to the way the function was coded... PROPOSAL 2: With
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information