search for: stackslotcoloring

Hi, Three new files added: lib\Analysis\ValueTracking.cpp lib\CodeGen\StackSlotColoring.cpp lib\CodeGen\LiveStackAnalysis.cpp Regards, Cédric -------------- next part -------------- A non-text attachment was scrubbed... Name: updVS2005prj.patch Type: application/octet-stream Size: 1064 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080607/1...

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been implemented, since the code...

...gt; What post-RA passes with want to run with virtual regs? > > The immediate one that precipitated this mail was PrologEpilogInserter. > However currently the only other pass we have disabled in WebAssemblyTargetMachine is MachineCopyPropagation. > Several passes (post-RA MachineLICM, StackSlotColoring) already only run if RA runs. > Everything else is running today. Currently that's ShrinkWrap, BranchFolder, ExpandPostRAPseudos, PostRAScheduler, GCMachineCodeAnalysis, MachineBlockPlacement, FuncletLayout, and StackMapLiveness. All of these run after our register coloring pass. I don’t kn...

...?id=1401 indicates that X86 does this well enough, but sure would be handy on ARM. There's a couple other areas I'm very interested in better understanding. For instance, I've read a couple papers on stack slot coloring, and I see that there's some work done already in the CodeGen/StackSlotColoring.cpp. I'd love to dig deeper into this topic. This project is still listed as open. Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals. Making th...

...lvmdev at cs.uiuc.edu > > Sent: Monday, October 13, 2014 8:29:38 AM > > Subject: [LLVMdev] Problem of stack slot coloring > > > > Hi, > > > > > > Can anyone help me with the stack slot coloring optimization? > > This corresponding file is /lib/codegen/stackslotcoloring.cpp. > > > > > > It is said this optimization was for stack slot overlay for frame > > size reduction, after register allocation phase. > > And this transformation pass relies on the LiveStack analysis pass. > > > > > > How, when checking the source c...

...ndicates that X86 does this well enough, but sure would be handy on ARM. > > There's a couple other areas I'm very interested in better understanding. For instance, I've read a couple papers on stack slot coloring, and I see that there's some work done already in the CodeGen/StackSlotColoring.cpp. I'd love to dig deeper into this topic. This project is still listed as open. > > Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals....

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- Original Message ----- >> From: "Quentin Colombet" <qcolombet at apple.com> >> To: "Derek Schuff" <dschuff at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org >> Sent: Wednesday, December

...r more here mentioned 3 tasks may be not a much work for some one who has a good grasp on llvm but for me it may be sufficient for GSoC duration. It may not be possible for Google to provide fundings for limited number of improvements. So I am thinking to include some TODOs in StackColoring.cpp and StackSlotColoring.cpp in proposal too. Will it be enough to demonstrate in proposal ? Still I am looking for feedback on RDF part and also if some one is willing to mentor me. Sincerely, Vivek > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

...that really just puts a new register definition in the final PTX and copies to/from this register when spilling/restoring is needed This could also work. Spill slots actually do what you want. The register allocator tries to use as few as possible as long as performance doesn't suffer. Later, StackSlotColoring will merge non-overlapping stack slot ranges to save more space. > I hesitate to use (1) or (3) as they rely too heavily on the final ptxas tool to perform reasonable register allocation, which may not lead to optimal code. Option (2) seems promising, though I worry about the feasibility of th...

Hello, I am a student at UFMG, Brazil, and I'm currently choosing my final undergraduate project. I will be working under Professor Fernando Pereira (on cc), and we were thinking about tackling Code Generator Improvement number 2 (at http://llvm.org/OpenProjects.html). How is the status on this project? Is it still open? Thanks for your time, Thiago Martins. -------------- next part

...be modified, the effects of disabling them, etc. Currently the following target-independent passes run after register allocation (ordered and categorized according to how they appear in lib/CodeGen/Passes.cpp): OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true for wasm) StackSlotColoring PostRAMachineLICM ShrinkWrap PrologEpilogInserter Machine late optimization: BranchFolderPass TailDuplicate MachineCopyPropagation PostRAScheduler ExpandPostRAPseudos ImplicitNullChecks (optional) PostMachineScheduler or PostRAScheduler GC: GCMachineCodeAnalysis GC info printer Block Placeme...

...llvm::EBCSubtarget::~EBCSubtarget()in libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) llvm::EBCSubtarget::~EBCSubtarget()in libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) "llvm::TargetOperandInfo::getRegClass(llvm::TargetRegisterInfo const*) const", referenced from: (anonymous namespace)::StackSlotColoring::PropagateForward(llvm::ilist_iterator<llvm::MachineInstr>, llvm::MachineBasicBlock*, unsigned int, unsigned int) in libLLVMCodeGen.a(StackSlotColoring.cpp.o) (anonymous namespace)::StackSlotColoring::PropagateBackward(llvm::ilist_it...

...them, etc. > > Currently the following target-independent passes run after register > allocation (ordered and categorized according to how they appear in > lib/CodeGen/Passes.cpp): > > OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true > for wasm) > StackSlotColoring > PostRAMachineLICM > ShrinkWrap > PrologEpilogInserter > Machine late optimization: > BranchFolderPass > TailDuplicate > MachineCopyPropagation > PostRAScheduler > ExpandPostRAPseudos > ImplicitNullChecks (optional) > PostMachineScheduler or PostRAScheduler &g...

Hello LLVM Community, I am interested doing following project with LLVM for GSoC 2016. Code Generation Improvements: Particularly Generalize target-specific backend passes that could be target-independent I have done some initial study and try to understand the task to be done. Please help me to develop the proposal. Following are my initial findings : 1. lib/Target/Hexagon/RDF* : Code

Hi Vivek, (Mostly responding with AArch64 hints, though anything I happen to know from elsewhere too). On 29 February 2016 at 13:00, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp > As far as I understand this pass promotes sign exertion for 32 bit integer ( > address) and performs calculation on 64 bit number

Currently, the TableGen register info files for all of the back-ends define concrete registers and divide them into logical register classes. I would like to get some input from the LLVM experts around here on how best to map this model to an architecture that does *not* have a concrete, pre-defined register file. The architecture is PTX, which is more of an intermediate form than a final

...rithms like if-conversion make use of the fact that the > block weights are additive. Are you talking about branch probabilities here? I don't believe we use block frequencies in anything other than: 1) MachineBlockPlacement 2) Spill cost, placement, and generally the register allocator 3) StackSlotColoring (but really only for spill weight computation) 4) LoopVectorizer (disabled currently) I just want to make sure we're on the same page. I don't think it really invalidates your concern. I'm sure they could be adapted to something more sophisticated, but these > heuristics are notori...

...he fact that the block weights are additive. >> >> Are you talking about branch probabilities here? I don't believe we use block frequencies in anything other than: >> 1) MachineBlockPlacement >> 2) Spill cost, placement, and generally the register allocator >> 3) StackSlotColoring (but really only for spill weight computation) >> 4) LoopVectorizer (disabled currently) >> >> I just want to make sure we're on the same page. I don't think it really invalidates your concern. > > You're right. I thought early if-conversion was multiplying the...

...ive. >>>> >>>> Are you talking about branch probabilities here? I don't believe we use block frequencies in anything other than: >>>> 1) MachineBlockPlacement >>>> 2) Spill cost, placement, and generally the register allocator >>>> 3) StackSlotColoring (but really only for spill weight computation) >>>> 4) LoopVectorizer (disabled currently) >>>> >>>> I just want to make sure we're on the same page. I don't think it really invalidates your concern. >>> >>> You're right. I thought...

...gt;>> Currently the following target-independent passes run after register allocation (ordered and categorized according to how they appear in lib/CodeGen/Passes.cpp): >>> >>> OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true for wasm) >>> StackSlotColoring >>> PostRAMachineLICM >>> ShrinkWrap >>> PrologEpilogInserter >>> Machine late optimization: >>> BranchFolderPass >>> TailDuplicate >>> MachineCopyPropagation >>> PostRAScheduler >>> ExpandPostRAPseudos >>&g...