kumasento
commented
3 years ago One possible solution:
- Update clast AST first to avoid conflicting iterator names. For instance,
iwill be renamed toi_2if it appears the second time. All the subsequent statements that refer to this instance ofiwill be replaced its actual usage toi_2. In this way, we get a symbol table that contains all the unique instances of each IV. - One possible problem is that, even we update clast, the data stored in the body of user statement are not changed. We could update the body expression, e.g., from
S0(i)toS0(i_2)if necessary, and leave the iterators field as it is. Such that we can figure out the mapping when finally processing the clast inConvertFromOpenScop. - When inserting a caller/callee pair into the symbol table, we bind them with their corresponding IV instances. For instance, we will store the exact instance that
S0(i)uses as its argument, which could bei,i_2, ori_3. - During the final op cloning stage, instead of building the mapping once and never update, we will update the mapping based on what IV instances that each statement binds to.
Sometimes Pluto may generate a Scop like this:
When it is handled by CLooG, there might be duplicated loop structures that iterate the polyhedra. In that case, the same statement can exist at different places in the code. For different placement, they could have exactly the same naming for their loop IVs, however, if so, our code that generates MLIR from Scop cannot handle well since it relies the fact that IV names to be unique.
We might need to fundamentally change the design of the symbol table. Or maybe we need to add a new pass to make things easier to handle.
Also note that there are conflicts in the naming of the statements as well. For instance, one S1 can be different places of the code due to Pluto and CLooG.