search for: rdfgraph

...ris 3, 3, 35809 >> ori 30, 3, 20615 >> here what I am looking for is that value in reg 30 is rematerilizable >> (can be recalculated) because this whole sequence is using constants to >> calculate the value that is in reg 30. >> So this is how I think I can use RDFGraph here, for statement >> ori 30, 3, 20615 >> reaching defs for reg 3 can be traced back on RDFGraph if it found to be >> (rematerilizable) then continue going backward on RDFGraph untill a live >> range of reg 3 does not end (in this example it will be lis 3, 12414) >> T...

...to implement. The data-flow graph that is the backbone of the framework resembles SSA, i.e. it does contain phi nodes, and the like, but it is not a pure SSA, since it uses physical registers, which can have any number of definitions. The graph itself is described in detail in the comments in RDFGraph.h. The intended use scenario is: 1. Build the data flow graph. 2. Perform a sequence of data-flow optimizations and update the graph in the process. 3. Update liveness. Currently, only two optimizations are implemented: - copy propagation, and - dead code elimination. The copy propagation algor...

...rzysztof Parzyszek <kparzysz at quicinc.com> Cc: llvm-dev at lists.llvm.org Subject: [EXT] Re: [llvm-dev] Register Dataflow Analysis on X86 Hi Krzysztof, Thanks for the reply, I'm starting to understand the graph structure and terminology much better now, especially with the document in RDFGraph.h. I'm still a bit confused about some of the behavior I'm seeing with the phi nodes that involve aggregate registers. Here is one example: b1531: --- %bb.36 --- preds(2): %bb.35, %bb.128 succs(1): %bb.37 p3193: phi [+d3194<RBP>(,,u3211):, u3195<RBP>(+d3170,b1526):u1...

Hi Scott, That #1073741833 is a register mask. They are treated as aggregate registers (essentially sets of registers), so if it includes R9D and R11D, it will be treated as being aliased with both. These separate defs are there because they reach disjoint registers. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: Scott

Hi Venu, > On Sep 11, 2017, at 11:00 PM, Raghavan, Venugopal via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Krzysztof, > > Thanks for your reply. > > I agree that adding extra register units for x86 would be the right way to fix this. Do you know if there is a plan to fix this? No concrete plan, no. We've been thinking about for quite some time now, but

...e historical reasons why it was introduced. > > -Krzysztof > > > > > On 10/30/2017 4:13 AM, Raghavan, Venugopal via llvm-dev wrote: > > Hi Krzysztof, > > I am returning to this thread after a gap in time. I took some time > to study the code in RDFGraph.cpp in the Hexagon directory. > > I have a few questions. I hope you will not find it too much of a > bother to answer them. > > 1) Does use node only support a single reaching def? If the RDF > graph is constructed post-RA, the code is no longer in SSA form and...

...e historical reasons why it was introduced. > > -Krzysztof > > > > > On 10/30/2017 4:13 AM, Raghavan, Venugopal via llvm-dev wrote: > > Hi Krzysztof, > > I am returning to this thread after a gap in time. I took some time > to study the code in RDFGraph.cpp in the Hexagon directory. > > I have a few questions. I hope you will not find it too much of a > bother to answer them. > > 1) Does use node only support a single reaching def? If the RDF > graph is constructed post-RA, the code is no longer in SSA form and...

...ode u65 in s61. It > has the d50 def ref node as a reaching definition. My question is: > shouldn’t we also be able to infer that the d49 ref node is a reaching > def node for u65? Starting from u65 there does not seem to be a way to > reach d49. > > I debugged the code in X86RDFGraph.cpp. It appears that when we start > from u65, we hit the def ref node d50 which covers u65 since both > involve ECX. Hence there is no need to look for other reaching defs. > > The node d50 itself is created as a def node because ECX appears as an > implicit def in the COPY inst...

...def ref node as a reaching definition. My question is: >>> shouldn’t we also be able to infer that the d49 ref node is a reaching def >>> node for u65? Starting from u65 there does not seem to be a way to reach >>> d49. >>> >>> I debugged the code in X86RDFGraph.cpp. It appears that when we start >>> from u65, we hit the def ref node d50 which covers u65 since both involve >>> ECX. Hence there is no need to look for other reaching defs. >>> >>> The node d50 itself is created as a def node because ECX appears as an >&g...