search for: preemitpass

...s makes sense and has come up before in discussions. I can envision a set of analyses that need to run after all MI modification but before asm printing. The StackMapLiveness pass is one such example. No enforcement mechanism exists yet, but it’s safe to say that nothing with modify MI after the addPreEmitPasses hook. For now you can just schedule your pass at the end with comments. > > We could introduce a fake MI analysis that should be invalidated by any pass that mutates the MI. Then check that it’s valid during code emission. That part is trivial. > > I think the real issue is that MC...

I think this after a second. I got your point. I can define a pseudo instruction for an instr-pair and expand it after post-RA-sched. as you said, in preEmitPass. The original intrinsic can also be kept. I just convert the intrinsic to pseudo instruction in TargetLower. Thank you for your enlightening suggestion! thanks, --lx On Sat, Nov 23, 2013 at 8:37 PM, Amara Emerson <amara.emerson at gmail.com>wrote: > What I meant was to write your own...

...re sane control flow. The code emitter still processes the blocks in the old order. So instead of going from 0-5, it prints out the instructions in the order, 0, 1, 2, 5, 3, 4. This is the order that the old CFG is in, not the new one after this pass is done. I've added this analysis pass as a PreEmitPass, is this the correct location to implement this? Or should I be implementing it earlier? Later? Thanks for any advice, ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, October 14, 2008...

On Oct 14, 2008, at 9:16 AM, Villmow, Micah wrote: > But, the branch folding pass, or whatever passes are supposed to > reorder the blocks based on the CFG, are not doing so in this case. > Otherwise there is no way that blocks 2 and 4 should be printing out > before blocks 3 & 5. Renumber blocks just seems to reorder the > values based on their pre-set block number,

What I meant was to write your own expansion pass and run it after the scheduler passes, e.g. in the pre-emit stage. > if (addPreEmitPass()) printAndVerify("After PreEmit passes") Though if it's too hacky for you then fair enough. Amara On 23 November 2013 03:17, Liu Xin <navy.xliu at gmail.com> wrote: > Amara, > > first, thank you for answering. but I found expandPsuedo instructions > actually...

Hi, I would like to execute a MachineFunctionPass after all other passes which modify the machine code. In other words, if we call llc to generate assembly file, that pass should run right before the "Assembly Printer" pass. Is there any official way to enforce this ? Best regards, Sebastien

Amara, first, thank you for answering. but I found expandPsuedo instructions actually happens before post-RA, like the following code showing: your approach is a little hacky, right? : ) // Expand pseudo instructions before second scheduling pass. addPass(&ExpandPostRAPseudosID); printAndVerify("After ExpandPostRAPseudos"); // Run pre-sched2 passes. if (addPreSched2())

...re sane control flow. The code emitter still processes the blocks in the old order. So instead of going from 0-5, it prints out the instructions in the order, 0, 1, 2, 5, 3, 4. This is the order that the old CFG is in, not the new one after this pass is done. I've added this analysis pass as a PreEmitPass, is this the correct location to implement this? Or should I be implementing it earlier? Later? Thanks for any advice, ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, October 14, 2008...

But, the branch folding pass, or whatever passes are supposed to reorder the blocks based on the CFG, are not doing so in this case. Otherwise there is no way that blocks 2 and 4 should be printing out before blocks 3 & 5. Renumber blocks just seems to reorder the values based on their pre-set block number, but when the CFG is modified these number should modified also to follow the new

...es. That way, the JIT/runtime can change without customizing LLVM. As far as hooking the new stack map support into the GCMetaData abstraction, I'm not sure how that would work. GCMachineCodeAnalysis is currently a standalone MI pass. We can't generate our stack maps here. Technically, a preEmitPass can come along later and reassign registers invalidating the stack map. That's why we generate the maps during MC lowering. So, currently, the new intrinsics are serving a different purpose than GCMetaData. I think someone working on GC support needs to be convinced that they really need the n...

...runtime can change without customizing LLVM. > > As far as hooking the new stack map support into the GCMetaData > abstraction, I'm not sure how that would work. GCMachineCodeAnalysis > is currently a standalone MI pass. We can't generate our stack maps > here. Technically, a preEmitPass can come along later and reassign > registers invalidating the stack map. That's why we generate the maps > during MC lowering. > > So, currently, the new intrinsics are serving a different purpose than > GCMetaData. I think someone working on GC support needs to be > convince...

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo

Does this count have to be exact, or just an accurate approximation? The back-end may add/remove registers fairly late in the codegen process, so if you need an exact count you may need to run *just* before the assembly printer. Perhaps we could introduce a special machine node that represents a shared memory allocation. The node's value would be the shared address space pointer of the

Yes, total number of PTX registers that will be emitted is exactly what I need. It's hard to figure out this in LLVM IR level. 2013/8/7 Justin Holewinski <justin.holewinski at gmail.com> > Is there any way you could approximate the register/instruction usage and > perform live-range analysis in a higher-level LLVM IR pass? I'm not sure > how useful NVPTXRegisterInfo