https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
--- Comment #8 from Sebastian Pop <spop at gcc dot gnu.org> --- > I would have expected at least each memory op to be in a separate "black box" We could have a pass before graphite that splits BBs with more than one write into blocks that contain one data write with all the operations and data reads needed to compute the stored value. This would allow more freedom to schedule BBs around. > if you follow the original go-out-of-SSA approach you'd have their effects > on the CFG edges. So a more complete fix would similarly handle uses. In other words: how do we handle reductions? As you remember, the original way was to expose reductions by rewriting out-of-SSA scalar dependences crossing basic blocks (loop-phi nodes, loop-close-phi nodes,) tagging the properties of the reduction (commutative, associative) on the array, and adding that info to the data dependence graph. By adding those properties to the dependence graph, we give the scheduler more freedom to select transforms. We moved away from rewriting scalar dependences out-of-SSA because we do not want to transform the code if the scheduler has no better transform to be done: we do not want to leave around inefficient memory reads/writes. Instead, we handle SSA names and create scalar references added to the dependence graph. We still need to tag scalar reductions with their associative properties to allow the scheduler to reorder the computations.
