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

[Krzysztof Parzyszek via llvm-dev]

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