search for: slotindexing

I have a live interval, and I would like to find out what SlotIndex the next use the register will occur? Is there any way to map a live interval back into instructions or SlotIndexes or blocks used by? - Thanks Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110120/fd429dbd/attachment.html>

I am looking for the slot index of a register around the given slot index Min. Is there a better way than the linear search: ... findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min ) ... for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg); mo; mo = mo->getNextOperandForReg() ) { SlotIndex si = SI->getInstructionIndex( use.getOperand().getParent() ); if(

HI Is there a public function equivalent of calling getIndex I would like to use some sort of starting slot info of a live interval in some pass. I need a way of comparing which virtual register is associated with an earlier source line without relying on any debug info. The relative order is preserved in my case. thanks shrey

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

Hi Lang, Just one more quick question. in LiveIntervalAnalysis.cpp In SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) Did you really mean to use for (MachineRegisterInfo::use_nodbg_iterator UI = MRI.use_nodbg_begin(Reg), UE = MRI.use_nodbg_end(); UI != UE; UI.skipInstruction()) {} Aren't we currently dealing with units,

2015-05-27 10:59 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: > > On 2015 May 27, at 10:24, Chandler Carruth <chandlerc at google.com> wrote: > > > >> On Wed, May 27, 2015 at 8:15 AM Chris Lattner <clattner at apple.com> > wrote: > >>> On May 26, 2015, at 11:20 PM, Quentin Colombet <qcolombet at apple.com> > wrote:

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI =

> On 2015 May 27, at 14:01, Alex L <arphaman at gmail.com> wrote: > > > > 2015-05-27 10:59 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: > > On 2015 May 27, at 10:24, Chandler Carruth <chandlerc at google.com> wrote: > > > >> On Wed, May 27, 2015 at 8:15 AM Chris Lattner <clattner at apple.com> wrote: > >>>

On 12/22/2016 4:02 PM, via llvm-dev wrote: > > /// Early-clobber register use/def slot. A live range defined at > /// Slot_EarlyCLobber interferes with normal live ranges killed at > /// Slot_Register. Also used as the kill slot for live ranges tied to an > /// early-clobber def. > Slot_EarlyClobber, > > What does this mean, exactly? My

Hi Sergei, I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a

> On May 27, 2015, at 2:18 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015 May 27, at 14:01, Alex L <arphaman at gmail.com> wrote: >> >> >> >> 2015-05-27 10:59 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: >>> On 2015 May 27, at 10:24, Chandler Carruth <chandlerc at google.com>

On Jan 20, 2011, at 5:37 AM, Jeff Kunkel wrote: > I have a live interval, and I would like to find out what SlotIndex the next use the register will occur? Is there any way to map a live interval back into instructions or SlotIndexes or blocks used by? Not really, you have to use the use-def chain. See SplitAnalysis::analyzeUses(). /jakob -------------- next part -------------- A non-text

On Jan 3, 2014, at 11:01 AM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 3, 2014, at 4:58 AM, Haishan <hndxvon at 163.com> wrote: > >> >> At 2014-01-01 04:36:21,"Andrew Trick" <atrick at apple.com> wrote: >> >> On Dec 31, 2013, at 3:52 AM, Haishan <hndxvon at 163.com> wrote: >> My update steps are shown

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Hi, I am having a bit of a time trying to figure out the scheme behind the slotindexing / liverange design. There seems to be several indexes mapped to the same instruction. Why is this? I take it, that it will always be true that for a LiveRange includes instructions with slotindexes [i:j), based on calls to SlotIndexes::getInstructionIndex(MI) ? However, LiveRange.valno->def,...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Are all of those sibling values guaranteed to ultimately derive from the >> same def, in the sense that they can be traced through copies, phis, >> etc. back to a single instruction? > > They are known the all come from the same value in the original live range from before live range splitting. Ok, that's

Hi Sergei, Andy, Sorry - I got distracted with some other work. I'm looking into this and PR13719 now. I'll let you know what I find out. Sergei - thanks very much for the investigation. That should help me pin this down. Cheers, Lang. On Tue, Aug 28, 2012 at 2:33 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, Lang, > > Thanks for the suggestion. >

On Jan 3, 2014, at 1:06 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 3, 2014, at 12:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> >> On Jan 3, 2014, at 11:01 AM, Andrew Trick <atrick at apple.com> wrote: >> >>> >>> On Jan 3, 2014, at 4:58 AM, Haishan <hndxvon at 163.com> wrote: >>>

Hi @llvm, building a debug version under MSVC 9 leads to a compiler error due to a mix of different types in a call to upper_bound. I have attached a hot-fix but I'm rather unsure if it should be applied as it is, since IMHO the reason is a MSVC library bug ("IMHO", because I don't know the requirements imposed to the predicate by the standard). Best regards Olaf Krzikalla