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