[llvm-dev] [GSoC] Prospective student for Unify ways to move code or check if code is safe to be moved

RITHIK SHARMA via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 30 13:48:22 PDT 2020


Thanks Whitney,

It was really very helpful! I've drafted a proposal [1] with my best
efforts, I hope it does justice to your expectations. Looking forward to
any feedback or suggestions.

1.
https://docs.google.com/document/d/1zrCCw1LSe2GktYVxywkRSVvgzcPrQD-rch0_6GkK3lc/edit?usp=sharing

Many thanks,
Rithik

On Sat, 28 Mar 2020 at 03:40, Whitney T Tsang <whitneyt at ca.ibm.com> wrote:

> Hi Rithik,
>
> CodeMoverUtils is not aimed for only loop transformations, it can be used
> by any transformation which want to move code or check if code is safe to
> be moved.
> It can currently do both hoist and sink but require control flow
> equivalent between the original location and the intended to be moved
> location.
> I would like to keep the API decoupled from loop, so other transformation
> can use it.
> In this project we want to limit the scope to loop transformations due to
> the time constraint, but we should keep in mind that it should be usable
> for any kind of transformations.
>
> My expectations for the proposal should contains
> 1. the problem we want to solve
> 2. expected end result
> - how many percentage of the loop transformations do you think can be
> changed to use the unified API at the end of the project?
> 3. roadmap + timeline
> a. identified all loop transformations which require code motion
> b. identified all existing code mover utilities
> c. understand the difference (some maybe more conservative, but does it
> really need to be)
> d. improve CodeMoverUtils to accommodate different users
> e. change existing loop transformations to use the improved CodeMoverUtils
> (should do with (d) at the same time).
>
> Note: finding transformations that use code motion is part of the project,
> so no need to include every opportunity in the proposal.
>
> Hope this help.
>
> Regards,
> Whitney Tsang
>
> [image: Inactive hide details for RITHIK SHARMA ---2020/03/27 03:08:47
> PM---Hello Whitney, I spent some good time going through the exa]RITHIK
> SHARMA ---2020/03/27 03:08:47 PM---Hello Whitney, I spent some good time
> going through the exact implementation of a few loop
>
> From: RITHIK SHARMA <rithiksh02 at gmail.com>
> To: whitneyt at ca.ibm.com
> Cc: etiotto at gmail.com, Stefanos Baziotis <stefanos.baziotis at gmail.com>,
> llvm-dev <llvm-dev at lists.llvm.org>, bmahjour at ca.ibm.com
> Date: 2020/03/27 03:08 PM
> Subject: [EXTERNAL] Re: [llvm-dev] [GSoC] Prospective student for Unify
> ways to move code or check if code is safe to be moved
> ------------------------------
>
>
>
> Hello Whitney,
>
> I spent some good time going through the exact implementation of a few
> loop transformation passes in llvm and for others, I tried to quickly get
> an idea of what is going inside them with respect to the implementation in
> llvm.
>
> I also went through the CodeMoverUtils [1], I really appreciate the effort
> of keeping it generic and decoupled from loop though being derived from
> loop and aimed to be used for loop transformation. I also analyzed Loop
> Fuse pass [2] as a reference as it already uses CodeMoverUtils which helped
> me to concrete my understanding of the vision behind the unification of
> code motion checks.
>
> LICM [3] does hoisting [4] as well as sinking [5]. I thought about
> extending the already available isSafeToMoveBefore [6] for hoisting the
> code from loop body to the pre-header. In my opinion, hosting and sinking
> are the basic code motions, exposing them in a robust and flexible way will
> also help other transformations (maybe other non-loop transformations).
>
> I also saw that Loop Sink pass [7] uses the same checks [8] from LICM and
> also found another code hoisting opportunity in Loop Rotation pass where we
> once hoist to the pre-header [9]. I also analyzed passes like Loop Unswitch
> [10] in the hope for some code motion opportunities but it seems the passes
> which are expected to run after LICM are void of them (may not be true for
> all). I limited myself to the loop passes in Transform/Scalar and I'm
> planning to take a look into other loop passes as well.
>
> Having said that, my concern right now is the proposal whose deadline is
> approaching in 4 days, I would like to get a small feedback before the
> deadline. I am aiming to prepare a draft by Monday morning (PST) so then I
> may have a short window to incorporate the feedback. I also have two
> coursework assignment deadlines end of this week which is also demanding
> some of my effort other than attending the lectures.
>
> I'll be glad to hear about your expectations for the proposal. I'm
> planning to somehow meet them and will also continue to look into loop
> passes for more code motion checks after the proposal deadline. Does this
> look good to you? In my proposal can I focus on the findings that I'm able
> to do before the deadline and keep some buffer for things that I may find
> later as identifying all the existing ways for code motion in loop
> transformations is a big portion of the proposed project.
>
> 1.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/CodeMoverUtils.cpp*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/CodeMoverUtils.cpp>
> 2.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopFuse.cpp*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopFuse.cpp>
> 3.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp>
> 4.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp#L353*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp#L353>
> 5.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp#L348*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LICM.cpp#L348>
> 6.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/CodeMoverUtils.cpp#L299*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/CodeMoverUtils.cpp#L299>
> 7.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopSink.cpp*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopSink.cpp>
> 8.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopSink.cpp#L303*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopSink.cpp#L303>
> 9.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/LoopRotationUtils.cpp#L403*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/LoopRotationUtils.cpp#L403>
> 10.
> *https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp*
> <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp>
>
> Best,
> Rithik
>
>
>
> On Tue, 24 Mar 2020 at 23:30, Stefanos Baziotis <
> *stefanos.baziotis at gmail.com* <stefanos.baziotis at gmail.com>> wrote:
>
>    Np, good luck! :)
>
>    - Stefanos
>
>    Στις Τρί, 24 Μαρ 2020 στις 8:55 μ.μ., ο/η RITHIK SHARMA <
>    *rithiksh02 at gmail.com* <rithiksh02 at gmail.com>> έγραψε:
>    Many thanks, Stefanos! I really appreciate your help :) I heard from
>    Whitney.
>
>    Best,
>    Rithik
>
>    On Tue, 24 Mar 2020 at 23:08, Stefanos Baziotis <
>    *stefanos.baziotis at gmail.com* <stefanos.baziotis at gmail.com>> wrote:
>       Hi Rithik,
>
>       I CC'd the 2 other mentors and hopefully you'll get answer. Sorry,
>       but I don't know of any other way to help. :/
>       You may also try to contact them privately.
>
>       Best,
>       Stefanos
>
>
>       Στις Τρί, 24 Μαρ 2020 στις 7:35 μ.μ., ο/η RITHIK SHARMA via
>       llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>>
>       έγραψε:
>       Ping!
>       I'm bit concern about the approaching deadline next week, some
>       pointers will be really appreciated and will be very helpful to me.
>
>       Best regards,
>       Rithik Sharma
>
>       On Sun, 22 Mar 2020 at 01:24, RITHIK SHARMA <*rithiksh02 at gmail.com*
>       <rithiksh02 at gmail.com>> wrote:
>          Hello,
>
>          I am an undergrad from India. This summer I'm interested in
>          working on unifying the code motion checks as a GSoC intern with LLVM. I
>          started reading about classical data flow analysis since few months, I see
>          this as a great opportunity to start contributing to LLVM. The idea of
>          unifying all the code motion checks into one place seems very rational and
>          interesting to me. As in the project description LICM was mentioned, I have
>          a basic idea about it and I spent some time to go through its
>          implementation in LLVM. It makes a lot of sense to me to keep all code
>          motion checks at one place, say an analysis pass, I also looked into GVN
>          hoist & sink passes as they also have some code motion logic. I'll start
>          drafting the proposal after your initial feedback/suggestions. I'm really
>          very excited to work on this.
>
>          Best Regards,
>          Rithik Sharma
>       _______________________________________________
>       LLVM Developers mailing list
> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>
> *https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev*
>       <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/dc16b5ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/dc16b5ad/attachment-0001.gif>


More information about the llvm-dev mailing list