rematerialization question

I am a bit confused how the rematerialization works.

It seems currently in our backend we get lots of code where some stack offset address is calculated, but this address is then spilled to stack, and loaded from stack later.

This does not make sense, it would be better to just recalculate the address later, ie rematerialize the original stack offset calculation.

But marking some instruction rematerializable means all operands have to be always available?

So I cannot make my add operation which is used for the stack offset calculations rematerializable because not all operands of all adds are always available?

So how can I make llvm to try to rematerialize only those stack offset adds, but not all adds?

And also, when I have the stack update code in beginning and at end of the functions, these stack+immediate adds/subs also should not be rematerialized as the sp has changed?

Hi Heikki,

I am a bit confused how the rematerialization works.

It seems currently in our backend we get lots of code where some stack
offset address is calculated, but this address is then spilled to stack,
and loaded from stack later.

This does not make sense, it would be better to just recalculate the
address later, ie rematerialize the original stack offset calculation.

But marking some instruction rematerializable means all operands have to
be always available?

Yes, the inline spiller will verify that condition.

So I cannot make my add operation which is used for the stack offset
calculations rematerializable because not all operands of all adds are
always available?

Well, you can mark your add operation as being rematerializable in your BE but it will not get remat'd if its operands are not available.

So how can I make llvm to try to rematerialize only those stack offset
adds, but not all adds?

You can force remat for those adds you want to by patching the spiller (see InlineSpiller.cpp). I did it for my target (a dirty patch though) but I cannot assure that remat will always be possible :(.

Regards,
Ivan