[llvm-dev] [GSoC 2016] Code Generation Improvements task

[vivek pandya via llvm-dev]

*Vivek Pandya*


On Wed, Mar 23, 2016 at 10:28 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote:
>
>>
>> Still I am looking for feedback on RDF part and also if some one is
>> willing to mentor me.
>
> Hello Krzysztof Parrzyszek,

I switched to other topic as I felt I don't have enough experience in
various backends. I also not tried to ask for guidance after I observed
long gap. So as far as GSoC is concerned it is not possible to make a solid
proposal with in a day. I need to read the papers related to RDF stuffs in
LLVM and also write up the whole initial search I did. But still I will
keep this mail in my mind and I will notify you if I work some thing on
this topic during my free time.

Hi Vivek,
> Sorry, I missed this email.  I wrote the RDF stuff and I'd be happy to
> help you out with it if you are interested.
>
> The idea was to have a utility class that would represent the data flow
> between registers.  The registers could be a mixture of virtual and
> physical, although the main application would be to use it on a post-RA
> code.  I decided against having it as a part of the pass manager, because
> the user does not have any direct control over the creation and
> invalidation of analyses, at least in the current version of the pass
> manager.  This does not mean that it cannot (or shouldn't) be used in an
> analysis, just that it should also be available as a standalone utility.
>
>
> The missing bits are:
>
> 1. Handling of regmasks
> This shouldn't be too hard.  All reference nodes (except those in phi
> nodes) have a pointer to the machine operand, from which the actual
> register is obtained.  Regmasks are different, since a single operand
> references multiple registers at once.  The way to handle them would be to
> treat a regmask as a register of its own that is aliased with the
> registers, whose clobbering it represents.
>
> 2. Recomputing liveness information on instruction level.
> The MI-level IR uses implicit operands to keep track of the liveness of
> aliased registers. These implicit operands serve no other purpose, but they
> may introduce apparent dependencies (that do not, in fact exist). RDF will
> ignore these implicit operands when constructing the DFG, and optimizations
> using RDF could produce code where the liveness information carried by
> these operands is no longer valid (the same goes for <kill> flags).  This
> information would need to be recomputed.  There is some code in there that
> does that for the <kill> flags, but it does not deal with the implicit
> operands at all.
>
> The only thing I understand here is 3 point because some thing similar I
have thought.


> 3. Making it work with ther targets.
> RDF is intended to handle code that contains both physical and virtual
> registers on any target, but it has only been tested (in some capacity) on
> post-RA code and only on Hexagon.  Making it fully target-independent would
> involve testing it with other targets.
> - There are "copy propagation" and "dead code elimination" passes that use
> RDF.  Both are also meant to be target-independent and could serve as a
> testing tool.
> - RDF liveness would need to be verified to work on other targets.  It is
> meant to recalculate block live-ins.
>
> 4. It is unknown what RDF will do with bundles.
> In theory, it should use the summary information from each bundle (without
> looking inside of bundles), but I have no idea whether there are any cases
> that would break it.  There is nothing to represent the data flow within a
> bundle: besides not having any representation for it now, the actual data
> flow there may be highly target-dependent.  This is more of a hypothetical
> question, at least for now, since it may be fairly complex to design and
> implement.
>
>
> Thanks for reply !

Sincerely,
Vivek


> -Krzysztof
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/bc9db89d/attachment.html>