similar to: [LLVMdev] command line option

On Sat, 14 Apr 2007, Fernando Magno Quintao Pereira wrote: > the info I was looking for. Could any of you tell me a little about it? > I mean, do I have to write something like: > > static cl::opt<bool> > EnableJoining("join-liveintervals", > cl::desc("Join compatible live intervals"), > cl::init(true)); > >

LiveVariables gives you something like liveness analysis: where each variable is alive, that is, across each basic blocks, where it is defined, and where it is killed. LiveIntervals gives you a linear representation of the variables as a set of intervals. Yes, it handle holes in the live ranges. There is a very nice description of these analysis and related data structures here:

Dear guys, I want to coalesce some copies, and I would like to know if there is any method that I can call, like JoinCopy from the old (LLVM 1.9) LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM 2.1), but I do not want to call this analysis, as I have my own. basically, I can determine that two virtuals do not overlap, and I know that it is safe to join them. In

Fernando Magno Quintao Pereira wrote: > LiveVariables gives you something like liveness analysis: where each > variable is alive, that is, across each basic blocks, where it is defined, > and where it is killed. If I read this correctly, it means that at each instruction there's a list of live variables? I'm trying to figure out how to get at this information to build the

I would like to make a suggestion. In the LiveIntervalAnalysis class, instead of numbering the instructions in the order in which basic blocks are stored in the machine function, use the df_ext_iterator. It will order the instruction according to the dominance tree (or it seems to be doing so). There are many advantages in doing this. One of them is that, once you traverse the dominance tree

On Thu, 21 Jun 2007, Fernando Magno Quintao Pereira wrote: > I would like to make a suggestion. In the LiveIntervalAnalysis class, > instead of numbering the instructions in the order in which basic blocks > are stored in the machine function, use the df_ext_iterator. It will order > the instruction according to the dominance tree (or it seems to be doing > so). There are many

Hi, Just my two cents: If I recall correctly, in some papers on the linear scan register allocation people described that they tried different orderings for instruction numbering, e.g. including DFS or based on the loop nesting levels, etc. There was no clear winner though. But let's see the numbers anyway. May be it really brings some improvements. -Roman Chris Lattner wrote: > On

Nice idea. Please also try using SmallPtrSet (with a sufficiently large size) instead of std::set for traversal after everything is working. Using std::set can really hurt compile time in case of large basic block numbers. Is there a way to dynamically adjust "SmallSize" based on number of basic blocks in the function? Evan On Jun 21, 2007, at 10:20 PM, Fernando Magno Quintao

On Dec 15, 2007, at 4:45 PM, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I want to coalesce some copies, and I would like to know if > there is > any method that I can call, like JoinCopy from the old (LLVM 1.9) > LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM > 2.1), > but I do not want to call this analysis, as I have my own.

Dear LLVM'ers, I am browsing the instruction schedulers available in llc, and there are many: -pre-RA-sched = {default, none, simple, simple-noitin, list-burr, list-tdrr, list-td} I looked into the sources in lib/CodeGen/SelectionDAG, and I could find implementation of Sethi-Ullman numbering, list scheduling, etc. Now, I wish I could find some comparison between the

Hi, guys, sometimes it would be good if I could get the maximum instruction index from the set of live intervals. In my local version I have added this method to LiveIntervals: /// Return the maximum index among the instruction indices. inline unsigned getMaxInstrIndex() const { return i2miMap_.size() * InstrSlots::NUM; } Is there something like this already in LiveIntervals? Do you

Dear LLVM'ers, in my register allocator, sometimes I have to spill virtuals that represent the same variable before SSA conversion. I would like to assign the same stack slot to these virtuals. Is there a way to recover this information from one of LLVM data structures? In other words, is it possible to discover which virtuals represent the same variable before SSA conversion by reading

Dear Dave, Evan, thank you for answering. What I did was to remove the implementation of most of the methods of SimpleRegisterCoalescing and put them in a single class (RegisterCoalescer_Impl) that is not an analysis. Any class that wants these methods, can extend this class privately, or can use a reference to an RegisterCoalescer_Impl object. I wish it would be possible to go even

Chris Lattner wrote: > No there isn't, unfortunately. I'd suggest building up/maintaining the > r2r map inside the coallescer. Once the coallescer is done with the > entire function, do a single pass over the function rewriting all the > coallesced vregs. Ok. I have a version with the coalescer separated from liveIntervalAnalysis. It still uses the r2r map but as we

Hi, Anton and Fernando have answered most of your questions. I don't have anything to add there. I do want to comment on the "conservative" nature of LiveIntervalAnalysis. I think the comment is misleading and is probably just a relic of early implementation. The biggest problem with the current implementation is the overly aggressive copy coalescer. Right now the

Dear LLVM'ers, I'm producing code for the PowerPC, and many often times it happens that the bytecodes generated by LLVM have phi-functions like: A4 = phi(A1, A2) A5 = phi(A1, A3) Where the 'A1' parameter appears in two different phi-functions. Could someone give me an example in "pseudo-assembly" that would produce code like that after being transformed into

Hey, David. just a curiosity: does your changes have any impact on the compilation time? E.g, did you try comparing the old version with the modified version using llc -time-passes? best, Fernando > > Ok. I have a version with the coalescer separated from > liveIntervalAnalysis. It still uses the r2r map but as we > discussed late last week, it looks like the rewrite is

On Fri, 22 Jun 2007, Fernando Magno Quintao Pereira wrote: > Actually, changing the ordering, with the current implementation of linear > scan that LLVM uses, will not bring improvements to the code. The register > allocator must be aware that the intervals are been visited in the order > of dominance between basic blocks. This allows to simplify the > implementation a bit, because

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

Hi Florian, we though about using UIUC, like in LLVM. Do you guys know if that could be a problem, given that we are mining the functions from github? > Have you thought about integrating the benchmarks as external tests into LLVM’s test-suite? That would make it very easy to play around with. We did not think about it actually. But we would be happy to do it, if the community accepts