Extending StoreInst/LoadInst

Hi,

I am trying to figure out the best way to add some extra metadata to the store and load llvm-ir instructions:

The metadata content is a 'Value*' expression representing a side channel, containing dependency information that is used to help the Scoped Alias Analysis.
Optimizations that don't know about this side channel can safely drop it, where the only effect would be on the alias analysis not being able to prove that certain
accesses will not alias.

As for the actual implementation, I am wondering what the recommended strategy is.

I am currently aware of:
1) 'metadata as value': this is supported for arguments (like in a call), but, as far as I see, not directly for generic metadata. Not sure how easy it is to add to StoreInst/LoadInst.
2) add an extra 'Value*' member to StoreInst and LoadInst (without changing the operands and the OperandTraits)
3) treat the side channel as (optional) operand 1 for load, and (optional) operand 2 for store. This involves changing the 'operator new' to always allocate for 2(load)/3(store) operands. Also OperandTraits of StoreInst must be modfied as we now have an optional operand.
  For the LoadInst, we also need to introduce an OperandTraits, to overrule the 'UnaryInstruction' one.
4) Introduce a StoreWithSideChannelInst/LoadWithSideChannelInst that inherits from StoreInst/LoadInst, together with its appropriate OperandTraits. This makes it harder to add/remove sidechannel information.

Thanks,

Jeroen Dobbelaere

Hi Jeroen,

Intrinsic functions would be a good way to model vendor specific features.

In your case, for example, you can create your own memory load intrinsic function, and one of the function arguments would be your side channel Value*.

Hope this helps

Best,
Bekket McClane

Hi Bekket,

This side channel is something that will be added to almost _all_ load/store instructions.
Implementing it by an intrinsic (either, mimicking the load/store, or right before the pointer value) has too much impact on existing analysis and optimizations.

The behavior of it can be viewed as some extra 'metadata' (similar to !scope and !noalias), except that it refers to an expression (like '%3) instead of a metadata entry.

Greetings,

Jeroen Dobbelaere

Hi Jeroen,

Intrinsic functions would be a good way to model vendor specific features.

In your case, for example, you can create your own memory load intrinsic
function, and one of the function arguments would be your side channel
Value*.

Hope this helps

Best,
Bekket McClane

[...]