[MemIntrinsics] Add an API to get elementtype attribute value. NFC.

[dantrushin]

Summary

Add simple wrappers to make CallBase::getParamElementType() available
to users of Memory Intrinsics. Some environments may need it when
opaque pointers are enabled.
Right now there are no users of these interfaces in tree, so this is NFC.

[nikic]

We generally do not add in-tree methods if they have no in-tree users. I'm also rather skeptical about what you're trying to do here -- this would need some more detailed explanation of the use case.

[dantrushin]

In D125690#3516808, @nikic wrote:

We generally do not add in-tree methods if they have no in-tree users. I'm also rather skeptical about what you're trying to do here -- this would need some more detailed explanation of the use case.

Intrinsics allow to specify element type of its pointer arguments via elementtype attribute.
Atomic memory intrinsics hide this possibility behind quite complicated hierarchy. This patch makes it accessible for any interested party. I don't see what's wrong with that?

[nikic]

In D125690#3516864, @dantrushin wrote:

In D125690#3516808, @nikic wrote:

We generally do not add in-tree methods if they have no in-tree users. I'm also rather skeptical about what you're trying to do here -- this would need some more detailed explanation of the use case.

Intrinsics allow to specify element type of its pointer arguments via elementtype attribute.
Atomic memory intrinsics hide this possibility behind quite complicated hierarchy. This patch makes it accessible for any interested party. I don't see what's wrong with that?

Use of elementtype is discouraged -- it should only be used if there is no other solution. I don't want to add APIs legitimizing its use in this context without justification. For example, consider the llvm.memcpy.element.unordered.atomic intrinsics which specify an element size as an additional argument, rather than a precise element type.

[dantrushin]

In D125690#3516881, @nikic wrote:

Use of elementtype is discouraged -- it should only be used if there is no other solution. I don't want to add APIs legitimizing its use in this context without justification. For example, consider the llvm.memcpy.element.unordered.atomic intrinsics which specify an element size as an additional argument, rather than a precise element type.

Copying arrays of pointers in environments with moving garbage collector is different from copying of 'primitive' types of the same types.
Well, I understand that upstream may not take it as a 'justification'.

Anyway, I think that discouraged part is worth more explicit mentioning in opaque pointers guide - thhat was not clear to me while reading it.

[dantrushin]

Looks like this has to live downstream. Still I think if upstream provides some public api (CallBase::getParamElementType) it should be available to all users

[apilipenko]

Copying arrays of pointers in environments with moving garbage collector is different from copying of 'primitive' types of the same types.
Well, I understand that upstream may not take it as a 'justification'.

GC support is a supported feature of LLVM upstream (https://llvm.org/docs/GarbageCollection.html). I think this is a totally fair justification for elementtype on memory transfer intrinsics. I would argue that elementtype might be a requirement for some of the GC strategies because without the type information we can't choose the right lowering for the intrinsic.

[aeubanks]

does using the size parameter not work for your use case? do you specifically need the type?

[anna]

In D125690#3538597, @aeubanks wrote:

does using the size parameter not work for your use case? do you specifically need the type?

Unfortunately, size is not a precise way of differentiating primitives from pointers. Depending on data layout, the pointer can have 4 or 8 bytes, which is the same as an int/long.

The specific use case for us is that when we lower these intrinsics, we need to know if we need to add the GC support for this (done in IR itself) or not. With opaque pointers without elementttype in the intrinsic, we lose this knowledge,

llvm/include/llvm/IR/IntrinsicInst.h

public:
   /// Use getDestAlign() instead.
   unsigned getDestAlignment() const {
     if (auto MA = getParamAlign(ARG_DEST))
       return MA->value();
     return 0;
   }
   MaybeAlign getDestAlign() const { return getParamAlign(ARG_DEST); }
 
+  Type *getDestElementType() const { return getParamElementType(ARG_DEST); }
+
   /// Set the specified arguments of the instruction.
   void setDest(Value *Ptr) {
     assert(getRawDest()->getType() == Ptr->getType() &&
            "setDest called with pointer of wrong type!");
     setArgOperand(ARG_DEST, Ptr);
   }
 
   /// FIXME: Remove this function once transition to Align is over.
if (auto MA = BaseCL::getParamAlign(ARG_SOURCE))
       return MA->value();
     return 0;
   }
 
   MaybeAlign getSourceAlign() const {
     return BaseCL::getParamAlign(ARG_SOURCE);
   }
 
+  Type *getSourceElementType() const { return getParamElementType(ARG_SOURCE); }
+
   void setSource(Value *Ptr) {
     assert(getRawSource()->getType() == Ptr->getType() &&
            "setSource called with pointer of wrong type!");
     BaseCL::setArgOperand(ARG_SOURCE, Ptr);
   }
 
   /// FIXME: Remove this function once transition to Align is over.
   /// Use the version that takes MaybeAlign instead of this one.