GitLab

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