This is an archive of the discontinued LLVM Phabricator instance.

Allow loops in non-affine subregions -- SCoP Detection
ClosedPublic

Authored by jdoerfert on Mar 8 2015, 10:30 AM.

Details

Summary
Allow loops in non-affine subregions -- SCoP Detection

  This will allow the ScopDetection to detect non-affine regions that
  contain loops. All loops contained will be collected and are
  accessible to later passes in order to adjust the access functions.
  As the loops are non-affine and will not be part of the polyhedral
  representation later, all accesses that are variant in these loops
  have to be over approximated as non-affine accesses. They are
  therefore handled the same way as other non-affine accesses.
  Additionally, we do not count non-affine loops for the profitability
  heuristic, thus a region with only a non-affine loop will only be
  detected if the general detection of loop free regions is enabled.

Diff Detail

Repository
rL LLVM

Event Timeline

jdoerfert updated this revision to Diff 21455.Mar 8 2015, 10:30 AM
jdoerfert retitled this revision from to Allow loops in non-affine subregions -- SCoP Detection.
jdoerfert updated this object.
jdoerfert added subscribers: Restricted Project, Unknown Object (MLST).
jdoerfert updated this revision to Diff 21457.Mar 8 2015, 1:00 PM
jdoerfert edited edge metadata.

Fixed a small error and updated tests accordingly

jdoerfert updated this object.Mar 8 2015, 1:01 PM
jdoerfert removed a reviewer: jdoerfert.
sebpop edited edge metadata.Mar 9 2015, 7:14 AM

LGTM.

How do we compute the set of memory locations that are touched by a non-affine approximated loop?
That is this part of the commit message:
"all accesses that are variant in these loops

have to be over approximated as non-affine accesses".

Do we just say that the full array is accessed, or is there a more precise description of the memory access that can be computed?

Do we just say that the full array is accessed, or is there a more precise description of the memory access that can be computed?

As for other non-affine accesses we use the constant range provided by ScalarEvolution to limit the effects but model it as an access to the whole array if the constant range is not helpfull.

This revision was automatically updated to reflect the committed changes.