./devel/polly, Polyhedral optimizations for LLVM

[ CVSweb ] [ Homepage ] [ RSS ] [ Required by ] [ Add to tracker ]


Branch: CURRENT, Version: 4.0.0, Package name: polly-4.0.0, Maintainer: pkgsrc-users

Polly is a high-level loop and data-locality optimizer and optimization
infrastructure for LLVM. It uses an abstract mathematical representation based
on integer polyhedra to analyze and optimize the memory access pattern of a
program. We currently perform classical loop transformations, especially tiling
and loop fusion to improve data-locality. Polly can also exploit OpenMP level
parallelism, expose SIMDization opportunities. Work has also be done in the
area of automatic GPU code generation.

For many users, however, it's not the existing optimizations in Polly that are
of most interest, but the new analyses and optimizations enabled by the Polly
infrastructure. At polyhedral.info you can get an idea of what has already been
done and what is possible in the context of polyhedral compilation.


Required to run:
[lang/gcc48-libs] [lang/llvm]

Required to build:
[lang/gcc48] [pkgtools/cwrappers]

Master sites:

SHA1: 97f288ef99240642af432fb59e079a4a0e2205e5
RMD160: 5e37430f0bc80a9a1acfce1643c02815609b2504
Filesize: 8578.141 KB

Version history: (Expand)


CVS history: (Expand)


   2017-03-17 23:38:18 by Adam Ciarcinski | Files touched by this commit (38)
Log message:
LLVM 4.0.0:
The minimum compiler version required for building LLVM has been raised to 4.8 \ 
for GCC and 2015 for Visual Studio.
The C API functions LLVMAddFunctionAttr, LLVMGetFunctionAttr, \ 
LLVMRemoveFunctionAttr, LLVMAddAttribute, LLVMRemoveAttribute, LLVMGetAttribute, \ 
LLVMAddInstrAttribute and LLVMRemoveInstrAttribute have been removed.
The C API enum LLVMAttribute has been deleted.
The definition and uses of LLVM_ATRIBUTE_UNUSED_RESULT in the LLVM source were \ 
replaced with LLVM_NODISCARD, which matches the C++17 [[nodiscard]] semantics \ 
rather than gcc’s __attribute__((warn_unused_result)).
The Timer related APIs now expect a Name and Description. When upgrading code \ 
the previously used names should become descriptions and a short name in the \ 
style of a programming language identifier should be added.
LLVM now handles invariant.group across different basic blocks, which makes it \ 
possible to devirtualize virtual calls inside loops.
The aggressive dead code elimination phase (“adce”) now removes branches \ 
which do not effect program behavior. Loops are retained by default since they \ 
may be infinite but these can also be removed with LLVM option \ 
-adce-remove-loops when the loop body otherwise has no live operations.
The llvm-cov tool can now export coverage data as json. Its html output mode has \ 
also improved.
   2017-01-05 12:54:32 by Adam Ciarcinski | Files touched by this commit (16) | Package updated
Log message:
Changes 3.9.1:
The LLVMContext gains a new runtime check (see LLVMContext::discardValueNames()) \ 
that can be set to discard Value names (other than GlobalValue). This is \ 
intended to be used in release builds by clients that are interested in saving \ 
CPU/memory as much as possible.
There is no longer a “global context” available in LLVM, except for the C API.
The autoconf build system has been removed in favor of CMake. LLVM 3.9 requires \ 
CMake 3.4.3 or later to build. For information about using CMake please see the \ 
documentation on Building LLVM with CMake. For information about the CMake \ 
language there is also a CMake Primer document available.
C API functions LLVMParseBitcode, LLVMParseBitcodeInContext, \ 
LLVMGetBitcodeModuleInContext and LLVMGetBitcodeModule having been removed. \ 
LLVMGetTargetMachineData has been removed (use LLVMGetDataLayout instead).
The C API function LLVMLinkModules has been removed.
The C API function LLVMAddTargetData has been removed.
The C API function LLVMGetDataLayout is deprecated in favor of LLVMGetDataLayoutStr.
The C API enum LLVMAttribute and associated API is deprecated in favor of the \ 
new LLVMAttributeRef API. The deprecated functions are LLVMAddFunctionAttr, \ 
LLVMAddTargetDependentFunctionAttr, LLVMRemoveFunctionAttr, LLVMGetFunctionAttr, \ 
LLVMAddAttribute, LLVMRemoveAttribute, LLVMGetAttribute, LLVMAddInstrAttribute, \ 
LLVMRemoveInstrAttribute and LLVMSetInstrParamAlignment.
TargetFrameLowering::eliminateCallFramePseudoInstr now returns an iterator to \ 
the next instruction instead of void. Targets that previously did MBB.erase(I); \ 
return; now probably want return MBB.erase(I);.
SelectionDAGISel::Select now returns void. Out-of-tree targets will need to be \ 
updated to replace the argument node and remove any dead nodes in cases where \ 
they currently return an SDNode * from this interface.
Added the MemorySSA analysis, which hopes to replace MemoryDependenceAnalysis. \ 
It should provide higher-quality results than MemDep, and be algorithmically \ 
faster than MemDep. Currently, GVNHoist (which is off by default) makes use of \ 
MemorySSA.
The minimum density for lowering switches with jump tables has been reduced from \ 
40% to 10% for functions which are not marked optsize (that is, compiled with \ 
-Os).
   2016-11-14 21:49:16 by Ryo ONODERA | Files touched by this commit (4) | Package updated
Log message:
Update to 3.9.0

Changelog:
* Polly directly available in clang/opt/bugpoint
* Increased analysis coverage
* Fine-grain dependences analysis
* Update of the isl math library
   2016-09-20 00:32:41 by Kamil Rytarowski | Files touched by this commit (1)
Log message:
Regenerate distinfo to fix build

Noted by <dh>
   2016-09-13 00:49:24 by Kamil Rytarowski | Files touched by this commit (7)
Log message:
Import LLVM Polly 3.8.1 as devel/polly

Polly is a high-level loop and data-locality optimizer and optimization
infrastructure for LLVM. It uses an abstract mathematical representation based
on integer polyhedra to analyze and optimize the memory access pattern of a
program. We currently perform classical loop transformations, especially tiling
and loop fusion to improve data-locality. Polly can also exploit OpenMP level
parallelism, expose SIMDization opportunities. Work has also be done in the
area of automatic GPU code generation.

For many users, however, it's not the existing optimizations in Polly that are
of most interest, but the new analyses and optimizations enabled by the Polly
infrastructure. At polyhedral.info you can get an idea of what has already been
done and what is possible in the context of polyhedral compilation.