==Graphite Call - 17.03.2010==
Attendees: Ramakrishna, Sebastian, Konrad, David
Scoplib dump from Graphite will be integrated in gcc 4.5. Autovect interaction: clean up should be done both in the output of Graphite and improve the autovect analysis. Ideally we would like to have autovect in the code generation from Graphite.
Plans for gcc4.6:
- sese region based scop detection
- code motion based on a data locality heuristic
- bump PPL version requirement to have PIP in PPL
- improve data dependence analysis to remove useless edges (with PIP)
==Graphite Call - 10.03.2010==
Attendees: Ramakrishna, Razya, Sebastian, Konrad, David
All SPEC 2006 benchmarks pass compile and runtime tests. Quality of Graphite is good for gcc4.5 release.
Plans for gcc4.6:
- SCoP-lib: no progress in integrating this into Graphite.
- Use ISL as a polyhedral lib in GCC
- Or ask the PPL folks to implement an ISL like data structure and the operations on it.
==Graphite Call - 03.03.2010==
Attendees: Ramakrishna, Razya, Sebastian, Tobias, Konrad
- IV type stuff (stuff)
- Using PPL min/max
- cleanup in the data dependency analysis
- interchange heuristic
- Try to add scop context and iteration domain to strides. This is very slow, but it is not needed. So it will be left out.
Interchange reduces runtime performance of some spec benchmarks (PR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42777 )
- dealII seems to work with new patch
- check if more conversions are necessary (look at sebastians code)
sebastian working on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
still to be analyzed the miscompile with -fgraphite-identity http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
==Graphite Call - 17.02.2010==
Attendees: David, Konrad, Ramakrishna, Ether, Tobias
- Merging trunk into graphite branch
- Types problems
- Moving changes to another function
- Sebastian will work on this type problems. Seems to have a solution for this problems.
- Ideas about future of Graphite
- Transformations outside of graphite
- Graphite should become a research tool
- scoplib as interchange format
- I new bug concerning dealII 43026
- Ramakrishna will reduce this testcase
- Git tester fixed
- limit_scops()
- Hides several bugs.
- Region detection
DominanceFrontier in gcc available.
- PDT information should be usable.
LLVM
- Prepare Regions for inclusion to LLVM 2.7
- LLVM coding guidelines
http://llvm.org/docs/WritingAnLLVMPass.html [Add RegionPass stuff]
- git diff 6460e5884d5d49b0f64da3de28d1e692176afd57 HEAD
- foucs on regionpass right now, find some bugs
- One bug in regionpassmanager if analysis are marked as invalid (Tobias will send out testcase)
- Last day to propose patch is 01.03.2010
- The basic functions of region stuff is finish
http://wiki.llvm.org/Polyhedral_optimization_framework contains explanation how to checkout polly.
- make polly run on windows seems not a simple task
==Graphite Call - 10.02.2010==
Attendees: Razya, Ramakrishna, Tobias, Konrad, David, Sebastian, Albert
- Dependency problem fixed
- Analysis did some shortcut in collection the dependence information
- As soon as it found a dependence in the outermost loop it stopped.
- Create a union of polyhedron for all dependences and track down all depencecies
- Fixed 42637. Also fixed 42479 and 42558.
- Release 4.5?
- Timeline. Waiting for less than 0 P1 bugs.
- Most of these are Graphite and VTA related.
- 21 P1 bugs, 6 Graphite related.
- Merge
- Soon to be done.
- Type problems
- Solve the problem in the backend or in the frontend.
- Not enough to analyze the constants.
- Tobias sends very limited patch out tomorrow.
- Passing information from the frontend to Graphite
- Antoniu is working on this with Konrad
- DO not use VTA, you could use builtins
- Scoplib work is going to start soon (INRIA intern)
- Add existentially quantified variables to scoplib
- Add in/out variables
- Sven proposes a more human readable syntax
==Graphite Call - 03.02.2010==
Attendees: Ramakrishna, Konrad, Albert, Razya, David, Sebastian, Tobias, ether
- GROW
- Konrad did a great Graphite talk
- Diego's talk about how to improve gcc
- WHOPR
- Type bug
- gloog_error does not work correct.
- Do not use CLooG error, but bail out earlier (during SCoP detection).
- graphite-scop-detection.c:397 in function graphite_can_represent_loop
- Using GMP values
- Depence analysis
- Still failing PR42637 (Konrad)
- Adding runtime tests
- FAILs with the runtime checks:
- interchange-12.c execution test
- block-{0,4,7}.c execution test
- run-id-1.f execution test
- Run kernels several times with different flags
- We need a merge from trunk (Tobi)
==Graphite Call - 27.01.2010==
Attendees: Tobias, Ramakrishna, David, Sebastian, Razya, ether, Jan
- DealII fixes (Ramakrishna)
- types_compatible_p, check if it is a better solution.
Data dependence bug 42637: http://gcc.gnu.org/bugruntimezilla/show_bug.cgi?id=42637
- Computing data dependence legality check wrong.
- Computed it in the right order at the beginning
- In transformed schedule we insert a dependence the reversed direction
- Paper "The violated dependence analysis"
- Ideas:
(A ==
<==> (A / B == {} && B / A == {}) A.strictly_contains(B) && B.strictly_contains(A) (We have to project out the scattering dimensions before)
- Two more machines for the SPEC benchmarks
- Context
- Inserting limits of parameters
- big constraints in integer dimension not problematic
- Insert relations in between parameters
- Further SPEC benchmarks failing
- 8 fail with parallelize loops.
- dealII is passing with -ffast-math in O3, h264 is failing
- Some good runtime results
- PR42771
- Failing because newly generated SCoP does not allow further analysis. Interaction of two SCoPs.
- Deadline of P1 bugs
- Get rid as soon as possible.
- ISL input/output format
http://repo.or.cz/w/isl.git/commit/66d4b6136e0021128861fbdca9d301c7748dc222
LLVM:
- Jan presented Polly to OpenCL guys
- PCP has to be done on the gcc team
==Graphite Call - 20.01.2010==
Attendees: Sebastian, David, Ether, Konrad, Ramakrishna, Li, Tobias
- Bugs:
- Depencency checks broken?
- Building of dependency polyhedron
- Order information comes from the scattering, not the LST
- dealII (Li, Ramakrishna, Tobias)
- Seems to be a time problem again
- scoplib
LooPo presentation
- Graphical representation
- LLVM Region
- merge Tobi's code into to the regionpass stuff hope to build "successorInfo" while building the region tree keep "successorInfo" in a help class that names "MERegion", a "region" with multi-exit if we finally found that helper class have only 1 exit, we can get a region from it and if we found it has multi-exits, we can merge it into the top level "multi-exit region" build a multi exit region, if we can reduce its exits into one exit, then we can get a single exit region and if we cant reduce the exit, then we can prove that the entry of this region will not lead any valid region, so we can mark it down or something (this step not implement yet), and we can merge the multi exits region into its parent multi exits region to compute the exits again, and drop some not neccessary exit, so we can compute exits (successorInfo) on the fly
not so understand the "ShortCut" hope to make popt print out region infomation first,
- merge Tobi's code into to the regionpass stuff hope to build "successorInfo" while building the region tree keep "successorInfo" in a help class that names "MERegion", a "region" with multi-exit if we finally found that helper class have only 1 exit, we can get a region from it and if we found it has multi-exits, we can merge it into the top level "multi-exit region" build a multi exit region, if we can reduce its exits into one exit, then we can get a single exit region and if we cant reduce the exit, then we can prove that the entry of this region will not lead any valid region, so we can mark it down or something (this step not implement yet), and we can merge the multi exits region into its parent multi exits region to compute the exits again, and drop some not neccessary exit, so we can compute exits (successorInfo) on the fly
==Graphite Call - 13.01.2010==
Attendees: Tobias, David, Razya, Ramakrishna, Sebastian, John, Ether, Konrad, Jan, Li, Albert, Michael
- Bug fixing:
- fixed bootstrap on graphite branch
- evaluate memory strides per loop
- do not recompute memory strides, cache them in the LST structure
- 42521: ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844
- 42221: ICE from '-Os -fgraphite-identity'
- 42393: internal compiler error: in check_loop_closed_ssa_use
- Richi fixed a bug linked to the fact that we hashed pointers and traversed the hash table
Remaining bugs to be fixed: http://tinyurl.com/ydjsmkv
- P1 bugs: 9 related to Graphite vs. 5 P1 bugs in other components of GCC
- Meeting at INRIA
- Li, Tobias, Razya, Albert, Ramakrishna, Konrad, Antoniu Pop, Sven
Talk about LooPo from Armin
- We can attend the phone call
- Loop interchange heuristics
- Memory strides calculated not evulated on bbs, but on loops (attached to LST)
- Remove COMPONENT_REF limitation in SCoP detection (requiered for SPEC stream)
- Automatic tester
- GCC17 does still not work
- Moving to CLooG isl
- work is started again
- 42681: CLooG generates "if (7*T_6%8 == 0)" where T_6 has a pointer type.
CLooG and a type system -> Better not, do it in the host compiler
- Bug in reduction detection?
- Graphite generates wrong code for slightly different matrix multiplication
- Not linked to data dependence part of reduction as -ffast-math is not used
- LLVM Graphite clone - called Polly
- John, Ether, Tobias working on this
- Tobias working on SCoP detection based on SESE regions
- Jan: make the polyhedral framework more modular
- Additional conference room available
- Always online
Access using SIP/VoIP e.g. ekiga. Call sip:00077723146@iptel.org
- US Dail in Number: 253-242-1593
- International: +1 253-242-1593
- No need to dail anything else. No PIN, no #, just call and you are in.
Tobias will connect it to the AT&T conference room, on the normal graphite calls
Phone call notes will be written interactively at http://etherpad.com/iptel-webconf-23146
- Feel free to create an agenda upfront