search for: df_ext_iterator

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 to find the live intervals, they will be contiguous, you don't have to handle holes. Could someone...

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 advantages in doing this. One of them is that, once > you traverse the dominance tree to find the live intervals, they will be > contiguous, you don't have to handle holes...

...function? Evan On Jun 21, 2007, at 10:20 PM, 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 advantages in doing this. One of them is that, > once > you traverse the dominance tree to find the live intervals, they > will be > contiguous, you do...

...Chris Lattner wrote: > 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 advantages in doing this. One of them is that, once >> you traverse the dominance tree to find the live intervals, they will be >> contiguous, you don't have...

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 you don't have to handle holes in the live ranges: the new ordering has the

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 Mar 1, 2014, at 7:15 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Sat, Mar 1, 2014 at 5:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > The current guidelines [1] on the use of the struct keyword are too > restrictive and apparently ignored. They limit the use of struct to > PODs, citing broken compilers. > > The guidelines are

On Apr 19, 2005, at 23:17, Vikram Adve wrote: > Have you looked at ExtractCodeRegion() and its siblings in > include/llvm/Transform/Utils/FunctionUtils.h? It seems to be what you > need. This is brilliant. In fact, it is nearly *exactly* what I need. On Apr 19, 2005, at 23:59, Chris Lattner wrote: > An Interval (and an Interval partition) is a concept with a lot of > compiler