[llvm-dev] Extending StoreInst/LoadInst

[Bekket McClane via llvm-dev]

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

> On Aug 31, 2018, at 4:20 PM, Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev