[LLVMdev] Being able to know the jitted code-size before emitting
Jonathan S. Shapiro
shap at eros-os.com
Fri Apr 4 12:27:45 PDT 2008
On Fri, 2008-04-04 at 12:15 -0700, Evan Cheng wrote:
> On Apr 4, 2008, at 11:58 AM, Jonathan S. Shapiro wrote:
> > In general, it is not possible to know jitted code size without
> > emitting. You can suppress the actual write of the instructions
> > themselves, but you have to do all of the work prior to that point.
> That's not true. llvm targets which support JIT have all the
> information necessary to calculate the size of every instructions.
> It's possible to compute instruction length without having to compute
> what bits are going to be emitted.
Evan: please explain how span-dependent branches are resolved in your
method. You don't need to compute the bits that will be emitted, but you
do need to compute the length of those bits. In most real
implementations, the two steps are therefore inseparable.
> > But the point is that you have to actually generate the code (at least
> > in memory) to do this analysis.
> JIT is responsible for relocation. It knows everything, including the
> distance between the source and destination. Codegen needs to resolve
> all this before jitting so it's always possible to compute the size of
> every instruction before actually code emission.
This is basically repeating what I already said. You can suppress the
actual write of the instructions, but you need to run all of the steps
of code generation up to (but excluding) emission if you need to resolve
span dependent branches.
Meta-observation: if you cared how big the jitted code was, presumably
there was some question about whether/where you had the space for the
code. Codegen will require at least that much space in order to answer
the question. Given which, the simplest approach is to go ahead and
generate the code provisionally and either (a) keep it or (b) discard
More information about the llvm-dev