search for: tailduplicatepass

Hi all, I have faced a little bit of a strange transformation from the TailDuplicatePass In CodeGen. When the pass clones the contents of TailBB into PredBB, the bundled instructions in TailBB are not bundled in PredBB. I think the reason why it is not bundled is that the 'DuplicateInstruction' function does not set up the flag of the first instruction of the bundle in Pred...

...C front-end, but also is capable of making other code nicer. After this pass is run, the CFG simplify pass should be run to clean up the mess. First, lib/CodeGen/TailDuplication.cpp says the pass name is -tailduplication, not -tailduplicate. Am I looking at the right pass? INITIALIZE_PASS(TailDuplicatePass, "tailduplication", "Tail Duplication", false, false) Second, SimplifyCFG is a FunctionPass, not a MachineFunctionPass. What cleanup pass is this description really referring to? Thanks! -David

...an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the patchpoint/stackmap. For now it might be possible to just fix BranchFolder (and also TailDuplicatePass::TailDuplicate) to use a backwards analysis as well, but if we really wanted to make sure that the liveness information was accurate when the stackmaps code looks at it, wouldn't we need to get rid of anything that supports forward liveness analysis? On Mon, Oct 13, 2014 at 8:27 PM, Andrew Tri...

...capable of making other code nicer. After this pass is run, the CFG > simplify pass should be run to clean up the mess. > > First, lib/CodeGen/TailDuplication.cpp says the pass name is > -tailduplication, not -tailduplicate. Am I looking at the right pass? > > INITIALIZE_PASS(TailDuplicatePass, "tailduplication", "Tail Duplication", > false, false) > > Second, SimplifyCFG is a FunctionPass, not a MachineFunctionPass. What > cleanup pass is this description really referring to? > > Thanks! > > -David &...

...instruction and then simply replaced %vreg2 with %vreg0 since they are connected through a PHI, but since the register classes differ, the resulting code is wrong. I've managed to get around this by inserting a COPY in TailDuplication but I don't know what the proper fix is to this. In TailDuplicatePass::ProcessPHI: const TargetRegisterClass *RC = MRI->getRegClass(DefReg); + const TargetRegisterClass *SrcRC = MRI->getRegClass(SrcReg); + + // If the register class of the PHI src is wider than the PHI def + // then we can't just use PHI src instead of PHI def in the cloned + // in...

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps