On Tue, Jul 16, 2019 at 09:50:25AM +0100, Jiong Wang wrote: > > Let me digest a little bit and do some coding, then I will come back. Some > issues can only shown up during in-depth coding. I kind of feel handling > aux reference in verifier layer is the part that will still introduce some > un-clean code. I'm still internalizing this discussion. Only want to point out that I think it's better to have simpler algorithm that consumes more memory and slower than more complex algorithm that is more cpu/memory efficient. Here we're aiming at 10x improvement anyway, so extra cpu and memory here and there are good trade-off to make. > >> If there is no dead insn elimination opt, then we could just adjust > >> offsets. When there is insn deleting, I feel the logic becomes more > >> complex. One subprog could be completely deleted or partially deleted, so > >> I feel just recalculate the whole subprog info as a side-product is > >> much simpler. > > > > What's the situation where entirety of subprog can be deleted? > > Suppose you have conditional jmp_imm, true path calls one subprog, false > path calls the other. If insn walker later found it is also true, then the > subprog at false path won't be marked as "seen", so it is entirely deleted. > > I actually thought it is in theory one subprog could be deleted entirely, > so if we support insn deletion inside verifier, then range info like > line_info/subprog_info needs to consider one range is deleted. I don't think dead code elim can remove subprogs. cfg check rejects code with dead progs. I don't think we have a test for such 'dead prog only due to verifier walk' situation. I wonder what happens :)
