Added Live-Range Reordering (LRR) for Polly. To build this feature one needs to give (to build also PPCG with Polly): cmake -DPOLLY_ENABLE_GPGPU_CODEGEN=On ... I got inspired heavily from llvm/tools/polly/lib/CodeGen/PPCGCodeGeneration.cpp - I duplicated the code existing there. Basically what I did was to: - use from PPCGCodeGeneration.cpp method PPCGCodeGeneration::createPPCGScop() to initialize the maps containing the dependence analysis data; - implement in IslScheduleOptimizer::runOnScop(Scop &S) a good part of the construct_cpu_schedule_constraints() function from PPCG's cpu.c to compute the LRR constraints.
thanks for the work, your experiments sound very promising. In any case, test cases would be needed.
Would it be possible to not require any part of ppcg? We only require a small part of it (the live-range reordering), having coupling with ppcg should not be necessary.
Thanks a lot for the patch! I took a shot at a first round of review :) I can be nitpicky, so we can hash out the details as we go along with the review.
Can we refactor this stuff to prevent code duplication between this and PPCGCodeGen?
Can we pull this out as well to prevent code duplication?
I am wary of global mutable state. Can we try to refactor this so that we don't need it?
Nit: prefer if(!LiveRangeReordering)
From what I can tell, this object is a ScopPass to maintain the same interface? I would much rather it not be a class, and more importantly, not a ScopPass, because it's really not a pass :)
I'd also prefer it to not even exist. Rather, we can just have a function called ppcg_scop createPPCGScop(const Scop &S) or something like that.
This seems quite error prone. Can we use a unique_ptr<ppcg_obj, (custom deallocator)> to free this safely?
@bollu Alex added the code duplication because I suggested him to do so. IMHO the live-range reordering should not depend on ppcg at all. ppcg is not written as a library so in terms of software quality, we should not use it as one. On the llvm mailing list we currently discuss the inclusion of isl. I don't think we will not do the same for ppcg, meaning that if live-range reordering depends on it, we would have to remove it again should Polly be included into LLVM main.
Agreed, we should not use global state if avoidable. It is problematic if Polly is used as a library.