Jeroen Dobbelaere via llvm-dev
2018-Aug-31 20:20 UTC
[llvm-dev] 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> 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
Jeroen Dobbelaere via llvm-dev
2018-Sep-01 06:23 UTC
[llvm-dev] Extending StoreInst/LoadInst
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 >[...]