[Mono-devel-list] [PATCH] Opcode decomposition

[Ben Maurer]

Hello,

Thanks for the comments.

On Mon, 2004-04-05 at 14:24, Paolo Molaro wrote:
> > +#define NEW_LOAD_MEMBASE(cfg,dest,source,offset,op) do { \
> > +		MonoInst* load_source; \
> > +		if (offset != 0) { \
> > +			MonoInst* offset_inst; \
> > +			NEW_ICONST (cfg, offset_inst, offset); \
> > +			MONO_INST_NEW (cfg, load_source, CEE_ADD); \
> > +			load_source->cil_code = source->cil_code; \
> > +			load_source->inst_left = source; \
> > +			load_source->inst_right = offset_inst; \
> > +			load_source->type = STACK_MP; \
> 
> STACK_MP is not always correct when you use the macro in this way.
> In the new jit we try to maintain the info on managed/unmanaged
> pointers, at least until burg is involved or going to a precise GC will
> be even more difficult than it already is.

I copied this code over from CEE_LDFLD, I am not sure exactly what I
should be doing here. And it should probably be fixed there too...

> > @@ -6337,10 +6358,12 @@
> >  	static MonoJitICallInfo *newarr_specific_info = NULL;
> >  	MonoJitICallInfo *info;
> >  	int i;
> > +	MonoCompile *cfg = data;
> 
> Put back this out of the fast path.

Even simpler, I can just change the `gpointer data' to a `MonoCompile*
cfg'. I am not sure why it is a gpointer, but that functionality is not
being used.

> > +
> > +decompose_again:
> 
> No gotos, please. It's also better to avoid creating a new MonoInst if
> it's not needed (it saves also the memcpy you introduce with *tree =
> *newinst).
Ah, it turns out I dont really need this behavior. I had another patch
on my tree that did, but I refactored it. So that will be gone. And I
can get rid of the memcpy.

Once I understand the required behavior for the first issue, I will post
a modified patch.

-- Ben