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

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.
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.

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.


-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

*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>

On 3/23/2016 3:59 PM, vivek pandya wrote:
>
> 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.
That's understandable.  Thank you for your interest!

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation