[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 abandoned this revision.
rogfer01 added a comment.

Upstream 

 recently amended the ABI spec so it looks to me this is not going to be needed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D48589/new/

https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D48589#1144976, @rogfer01 wrote:

> @rjmccall because we do not want to impact the clients of `ABIArgInfo` I 
> thought of two possible approaches
>
> 1. extend `CGFunctionInfo` with a third trailing array (now it has two), with 
> as many elements as `ABIArgInfo` (call it `ABIArgExtraInfo`) then during the 
> creation of `CGFunctionInfo` link (somehow, see discussion below) each 
> `ABIArgInfo`to its corresponding `ABIArgExtraInfo`.
> 2. add a dynamic container like a `SmallVector` in 
> `CGFunctionInfo` and allocate `ABIArgExtraInfo` as needed.
>
>   In both cases during `getFOO`, `ABIArgInfo` would put the extra (less 
> commonly used) data into the corresponding `ABIArgExtraInfo` (overflowing 
> object).
>
>   In both cases too, we need a way to navigate to our enclosing 
> `CGFunctionInfo` but strictly only during the `getFOO` that fills the 
> `ABIArgInfo`. Getting it from the users is not possible, so we would need a 
> pointer to `CGFunctionInfo` in `ABIArgInfo` (set up during the creation of 
> `CGFunctionInfo`). That said, there is no need of its value all the time, 
> only at the beginning of `getFOO`. We could reuse its storage to point the  
> overflowing object (if needed, and set it to null otherwise).
>
>   Do any of the approaches look any close to what you had in mind? Perhaps 
> I'm missing the point.


Well, there's no point in having a trailing array that's always got the same 
number of elements as there are `ABIArgInfo`s, because then we're not actually 
saving any memory.  What I was thinking was that the representation of 
`ABIArgInfo` doesn't really change when it's being passed around as an 
independent value, but when it's stored in a `CGFunctionInfo`, we break it up 
into two components: one that stores all the stuff that frequently appears in 
`ABIArgInfo`s (which can go in a trailing array indexed by argument index) and 
one for all the uncommon information (which can go in a condensed trailing 
array indexed by nothing externally meaningful).  When you ask a 
`CGFunctionInfo` for the `ABIArgInfo` for the kth argument, it has to 
reassemble it, which it does by getting the common-subset `ABIArgInfo`, asking 
whether it needs any extra information, and (if so) pulling that out of the 
second array.  Storing the common-subset data together with an index into the 
trailing array (actually, this could reasonably just be a 32-bit byte offset 
from the address point of the CGFunctionInfo, which would be more efficient 
when recreating the `ABIArgInfo` and would also let us use the zero offset to 
mean there's no extra information) should be doable in 64 bits, vs. 192 bits in 
the current representation, so it's a significant savings even before we start 
adding new fields to `ABIArgInfo`.


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 added a comment.

@rjmccall because we do not want to impact the clients of `ABIArgInfo` I 
thought of two possible approaches

1. extend `CGFunctionInfo` with a third trailing array (now it has two), with 
as many elements as `ABIArgInfo` (call it `ABIArgExtraInfo`) then during the 
creation of `CGFunctionInfo` link (somehow, see discussion below) each 
`ABIArgInfo`to its corresponding `ABIArgExtraInfo`.
2. add a dynamic container like a `SmallVector` in 
`CGFunctionInfo` and allocate `ABIArgExtraInfo` as needed.

In both cases during `getFOO`, `ABIArgInfo` would put the extra (less commonly 
used) data into the corresponding `ABIArgExtraInfo` (overflowing object).

In both cases too, we need a way to navigate to our enclosing `CGFunctionInfo` 
but strictly only during the `getFOO` that fills the `ABIArgInfo`. Getting it 
from the users is not possible, so we would need a pointer to `CGFunctionInfo` 
in `ABIArgInfo` (set up during the creation of `CGFunctionInfo`). That said, 
there is no need of its value all the time, only at the beginning of `getFOO`. 
We could reuse its storage to point the  overflowing object (if needed, and set 
it to null otherwise).

Do any of the approaches look any close to what you had in mind? Perhaps I'm 
missing the point.

Thank you!


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 updated this revision to Diff 153070.
rogfer01 added a comment.

ChangeLog:

- Use a  `ConstantDataArray` instead of a struct of types.
- Use `LLVM_IS_TRIVIALLY_COPYABLE`


https://reviews.llvm.org/D48589

Files:
  include/clang/CodeGen/CGFunctionInfo.h
  lib/CodeGen/CGCall.cpp

Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1951,7 +1951,6 @@
 
   case ABIArgInfo::CoerceAndExpand:
 break;
-
   case ABIArgInfo::Expand:
 llvm_unreachable("Invalid ABI kind for return argument");
   }
@@ -1987,6 +1986,8 @@
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
   }
 
+  SmallVector CoerceAndExpandAttrs(IRFunctionArgs.totalIRArgs());
+  bool CoerceAndExpandHasAttributes = false;
   unsigned ArgNo = 0;
   for (CGFunctionInfo::const_arg_iterator I = FI.arg_begin(),
   E = FI.arg_end();
@@ -2055,9 +2056,39 @@
 }
 case ABIArgInfo::Ignore:
 case ABIArgInfo::Expand:
-case ABIArgInfo::CoerceAndExpand:
   break;
+case ABIArgInfo::CoerceAndExpand:
+  if (AI.getExtendSeq()) {
+// Handle extends in expanded items
+unsigned FirstIRArg, NumIRArgs;
+std::tie(FirstIRArg, NumIRArgs) = IRFunctionArgs.getIRArgs(ArgNo);
+llvm::StructType *CoercionType = AI.getCoerceAndExpandType();
+for (unsigned I = 0, Ext = 0; I < NumIRArgs; I++) {
+  llvm::Type *EltType = CoercionType->getElementType(I);
+  if (ABIArgInfo::isPaddingForCoerceAndExpand(EltType))
+continue;
 
+  uint64_t ExtendKind = AI.getExtendSeq()->getElementAsInteger(Ext++);
+  switch (ABIArgInfo::getExtendKind(ExtendKind)) {
+  case ABIArgInfo::ExtendKind::None:
+break;
+  case ABIArgInfo::ExtendKind::SignExt: {
+CoerceAndExpandHasAttributes = true;
+CoerceAndExpandAttrs[FirstIRArg + I].addAttribute(
+llvm::Attribute::SExt);
+break;
+  }
+  case ABIArgInfo::ExtendKind::ZeroExt: {
+CoerceAndExpandHasAttributes = true;
+CoerceAndExpandAttrs[FirstIRArg + I].addAttribute(
+llvm::Attribute::ZExt);
+break;
+  }
+  }
+}
+  }
+
+  break;
 case ABIArgInfo::InAlloca:
   // inalloca disables readnone and readonly.
   FuncAttrs.removeAttribute(llvm::Attribute::ReadOnly)
@@ -2112,12 +2143,16 @@
 if (FI.getExtParameterInfo(ArgNo).isNoEscape())
   Attrs.addAttribute(llvm::Attribute::NoCapture);
 
-if (Attrs.hasAttributes()) {
+if (Attrs.hasAttributes() || CoerceAndExpandHasAttributes) {
   unsigned FirstIRArg, NumIRArgs;
   std::tie(FirstIRArg, NumIRArgs) = IRFunctionArgs.getIRArgs(ArgNo);
   for (unsigned i = 0; i < NumIRArgs; i++)
+  {
+llvm::AttrBuilder CoerceAndExpandMergedAttrs(Attrs);
+CoerceAndExpandMergedAttrs.merge(CoerceAndExpandAttrs[FirstIRArg + i]);
 ArgAttrs[FirstIRArg + i] =
-llvm::AttributeSet::get(getLLVMContext(), Attrs);
+llvm::AttributeSet::get(getLLVMContext(), CoerceAndExpandMergedAttrs);
+  }
 }
   }
   assert(ArgNo == FI.arg_size());
Index: include/clang/CodeGen/CGFunctionInfo.h
===
--- include/clang/CodeGen/CGFunctionInfo.h
+++ include/clang/CodeGen/CGFunctionInfo.h
@@ -22,8 +22,10 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/Type.h"
 #include "llvm/IR/DerivedTypes.h"
+#include "llvm/IR/Constants.h"
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/Support/TrailingObjects.h"
+#include "llvm/Support/type_traits.h"
 #include 
 
 namespace clang {
@@ -76,16 +78,20 @@
 KindLast = InAlloca
   };
 
+  enum class ExtendKind : unsigned { None = 1, SignExt = 2, ZeroExt = 3 };
+
 private:
+
   llvm::Type *TypeData; // canHaveCoerceToType()
   union {
 llvm::Type *PaddingType; // canHavePaddingType()
 llvm::Type *UnpaddedCoerceAndExpandType; // isCoerceAndExpand()
   };
   union {
-unsigned DirectOffset; // isDirect() || isExtend()
-unsigned IndirectAlign;// isIndirect()
-unsigned AllocaFieldIndex; // isInAlloca()
+llvm::ConstantDataArray *ExtendSeq; // isCoerceAndExpand()
+unsigned DirectOffset;  // isDirect() || isExtend()
+unsigned IndirectAlign; // isIndirect()
+unsigned AllocaFieldIndex;  // isInAlloca()
   };
   Kind TheKind;
   bool PaddingInReg : 1;
@@ -110,13 +116,16 @@
 UnpaddedCoerceAndExpandType = T;
   }
 
-  ABIArgInfo(Kind K)
-  : TheKind(K), PaddingInReg(false), InReg(false) {
+  void setExtendSet(llvm::ConstantDataArray *ES) {
+assert(isCoerceAndExpand());
+ExtendSeq = ES;
   }
 
+  ABIArgInfo(Kind K) : TheKind(K), PaddingInReg(false), InReg(false) {}
+
 public:
   ABIArgInfo()
-  : TypeData(nullptr), PaddingType(nullptr), 

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:90
   union {
-unsigned DirectOffset; // isDirect() || isExtend()
-unsigned IndirectAlign;// isIndirect()
-unsigned AllocaFieldIndex; // isInAlloca()
+llvm::StructType *ExtendSeq; // isCoerceAndExpand()
+unsigned DirectOffset;   // isDirect() || isExtend()

rogfer01 wrote:
> rjmccall wrote:
> > Hmm.  I understand the need to use something uniqued here, but I think it 
> > would probably be more natural to at least use a `llvm::ConstantDataArray` 
> > (which could be null if there are no interesting bits) instead of encoding 
> > the information into the types of a struct type.  That would also make it 
> > easy to generalize the elements to an arbitrary flags type.
> > 
> > Also, on 64-bit targets this will increase the size of an `ABIArgInfo` to 
> > four pointers from three.  That's fine to the extent that we work with 
> > independent `ABIArgInfo`s, but I'm getting a little annoyed at the storage 
> > overhead of the array of `ABIArgInfo`s in `CGFunctionInfo` given that, in 
> > the overwhelmingly common case, an `ABIArgInfo` is no more than a kind and 
> > maybe a few of these flags.  Maybe there's some reasonable way to optimize 
> > the storage of an `ABIArgInfo` in a `CGFunctionInfo` so that we only need 
> > the extra storage in less-common cases?  Like extracting out a base class 
> > that's the Kind+Flags and making the main array be an array of those + an 
> > optional index into a second trailing array of full `ABIArgInfo`s.
> > 
> > I might be overthinking this, though.
> Oh, of course, using a value rather than a type is more sensible. I will 
> change this.
> 
> The idea of having a lighter `ABIArgInfo` and an ancillary extra array for it 
> seems sensible. I guess it may depend on how early/late we know the precise 
> kind of `ABIArgInfo` we need to represent. I haven't looked at this yet, I'll 
> investigate.
`CGFunctionInfo` should be totally immutable and just ultimately constructed 
with an array of `ABIArgInfo`, which seems like a reasonable place to inject 
some representation tricks.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:475
 
+static_assert(std::is_trivially_copyable::value,
+"ABIArgInfo must be trivially copyable as it is embedded as trailing "

rogfer01 wrote:
> rogfer01 wrote:
> > I think this is the right trait here. I spent too much time debugging this 
> > :)
> But today I realised that GCC 4.9 does not implement this so it will have to 
> go away :(
You could gate it on the compiler if you want, maybe extracting a 
`HAS_IS_TRIVIALLY_COPYABLE` test macro in `llvm/Support/type_traits.h` out of 
the implementation of `llvm::isPodLike`.


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 added inline comments.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:90
   union {
-unsigned DirectOffset; // isDirect() || isExtend()
-unsigned IndirectAlign;// isIndirect()
-unsigned AllocaFieldIndex; // isInAlloca()
+llvm::StructType *ExtendSeq; // isCoerceAndExpand()
+unsigned DirectOffset;   // isDirect() || isExtend()

rjmccall wrote:
> Hmm.  I understand the need to use something uniqued here, but I think it 
> would probably be more natural to at least use a `llvm::ConstantDataArray` 
> (which could be null if there are no interesting bits) instead of encoding 
> the information into the types of a struct type.  That would also make it 
> easy to generalize the elements to an arbitrary flags type.
> 
> Also, on 64-bit targets this will increase the size of an `ABIArgInfo` to 
> four pointers from three.  That's fine to the extent that we work with 
> independent `ABIArgInfo`s, but I'm getting a little annoyed at the storage 
> overhead of the array of `ABIArgInfo`s in `CGFunctionInfo` given that, in the 
> overwhelmingly common case, an `ABIArgInfo` is no more than a kind and maybe 
> a few of these flags.  Maybe there's some reasonable way to optimize the 
> storage of an `ABIArgInfo` in a `CGFunctionInfo` so that we only need the 
> extra storage in less-common cases?  Like extracting out a base class that's 
> the Kind+Flags and making the main array be an array of those + an optional 
> index into a second trailing array of full `ABIArgInfo`s.
> 
> I might be overthinking this, though.
Oh, of course, using a value rather than a type is more sensible. I will change 
this.

The idea of having a lighter `ABIArgInfo` and an ancillary extra array for it 
seems sensible. I guess it may depend on how early/late we know the precise 
kind of `ABIArgInfo` we need to represent. I haven't looked at this yet, I'll 
investigate.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:475
 
+static_assert(std::is_trivially_copyable::value,
+"ABIArgInfo must be trivially copyable as it is embedded as trailing "

rogfer01 wrote:
> I think this is the right trait here. I spent too much time debugging this :)
But today I realised that GCC 4.9 does not implement this so it will have to go 
away :(


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:90
   union {
-unsigned DirectOffset; // isDirect() || isExtend()
-unsigned IndirectAlign;// isIndirect()
-unsigned AllocaFieldIndex; // isInAlloca()
+llvm::StructType *ExtendSeq; // isCoerceAndExpand()
+unsigned DirectOffset;   // isDirect() || isExtend()

Hmm.  I understand the need to use something uniqued here, but I think it would 
probably be more natural to at least use a `llvm::ConstantDataArray` (which 
could be null if there are no interesting bits) instead of encoding the 
information into the types of a struct type.  That would also make it easy to 
generalize the elements to an arbitrary flags type.

Also, on 64-bit targets this will increase the size of an `ABIArgInfo` to four 
pointers from three.  That's fine to the extent that we work with independent 
`ABIArgInfo`s, but I'm getting a little annoyed at the storage overhead of the 
array of `ABIArgInfo`s in `CGFunctionInfo` given that, in the overwhelmingly 
common case, an `ABIArgInfo` is no more than a kind and maybe a few of these 
flags.  Maybe there's some reasonable way to optimize the storage of an 
`ABIArgInfo` in a `CGFunctionInfo` so that we only need the extra storage in 
less-common cases?  Like extracting out a base class that's the Kind+Flags and 
making the main array be an array of those + an optional index into a second 
trailing array of full `ABIArgInfo`s.

I might be overthinking this, though.


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 created this revision.
rogfer01 added a reviewer: rjmccall.

This is WIP and it is motivated by the suggestions in 
http://lists.llvm.org/pipermail/cfe-dev/2018-June/058263.html

First attempt, piggybacking the extend information in a structure where the 
bit-width of the integer represents the exact extension intended. There is a 
bit of overlapping with the original Extend but I'm not convinced we win 
anything from rewriting it into the new representation.

I plan to test this using unit tests but I can link a diff with the current 
usage in case it helps.


https://reviews.llvm.org/D48589

Files:
  include/clang/CodeGen/CGFunctionInfo.h
  lib/CodeGen/CGCall.cpp

Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1951,7 +1951,6 @@
 
   case ABIArgInfo::CoerceAndExpand:
 break;
-
   case ABIArgInfo::Expand:
 llvm_unreachable("Invalid ABI kind for return argument");
   }
@@ -1987,6 +1986,8 @@
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
   }
 
+  SmallVector CoerceAndExpandAttrs(IRFunctionArgs.totalIRArgs());
+  bool CoerceAndExpandHasAttributes = false;
   unsigned ArgNo = 0;
   for (CGFunctionInfo::const_arg_iterator I = FI.arg_begin(),
   E = FI.arg_end();
@@ -2055,9 +2056,39 @@
 }
 case ABIArgInfo::Ignore:
 case ABIArgInfo::Expand:
-case ABIArgInfo::CoerceAndExpand:
   break;
+case ABIArgInfo::CoerceAndExpand:
+  if (AI.getExtendSeq()) {
+// Handle extends in expanded items
+unsigned FirstIRArg, NumIRArgs;
+std::tie(FirstIRArg, NumIRArgs) = IRFunctionArgs.getIRArgs(ArgNo);
+llvm::StructType *CoercionType = AI.getCoerceAndExpandType();
+for (unsigned I = 0, Ext = 0; I < NumIRArgs; I++) {
+  llvm::Type *EltType = CoercionType->getElementType(I);
+  if (ABIArgInfo::isPaddingForCoerceAndExpand(EltType))
+continue;
 
+  llvm::Type *ExtendKind = AI.getExtendSeq()->getElementType(Ext++);
+  switch (ABIArgInfo::getExtendKind(ExtendKind)) {
+  case ABIArgInfo::ExtendKind::None:
+break;
+  case ABIArgInfo::ExtendKind::SignExt: {
+CoerceAndExpandHasAttributes = true;
+CoerceAndExpandAttrs[FirstIRArg + I].addAttribute(
+llvm::Attribute::SExt);
+break;
+  }
+  case ABIArgInfo::ExtendKind::ZeroExt: {
+CoerceAndExpandHasAttributes = true;
+CoerceAndExpandAttrs[FirstIRArg + I].addAttribute(
+llvm::Attribute::ZExt);
+break;
+  }
+  }
+}
+  }
+
+  break;
 case ABIArgInfo::InAlloca:
   // inalloca disables readnone and readonly.
   FuncAttrs.removeAttribute(llvm::Attribute::ReadOnly)
@@ -2112,12 +2143,16 @@
 if (FI.getExtParameterInfo(ArgNo).isNoEscape())
   Attrs.addAttribute(llvm::Attribute::NoCapture);
 
-if (Attrs.hasAttributes()) {
+if (Attrs.hasAttributes() || CoerceAndExpandHasAttributes) {
   unsigned FirstIRArg, NumIRArgs;
   std::tie(FirstIRArg, NumIRArgs) = IRFunctionArgs.getIRArgs(ArgNo);
   for (unsigned i = 0; i < NumIRArgs; i++)
+  {
+llvm::AttrBuilder CoerceAndExpandMergedAttrs(Attrs);
+CoerceAndExpandMergedAttrs.merge(CoerceAndExpandAttrs[FirstIRArg + i]);
 ArgAttrs[FirstIRArg + i] =
-llvm::AttributeSet::get(getLLVMContext(), Attrs);
+llvm::AttributeSet::get(getLLVMContext(), CoerceAndExpandMergedAttrs);
+  }
 }
   }
   assert(ArgNo == FI.arg_size());
Index: include/clang/CodeGen/CGFunctionInfo.h
===
--- include/clang/CodeGen/CGFunctionInfo.h
+++ include/clang/CodeGen/CGFunctionInfo.h
@@ -25,6 +25,7 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/Support/TrailingObjects.h"
 #include 
+#include 
 
 namespace clang {
 namespace CodeGen {
@@ -76,16 +77,20 @@
 KindLast = InAlloca
   };
 
+  enum class ExtendKind : unsigned { None = 1, SignExt = 2, ZeroExt = 3 };
+
 private:
+
   llvm::Type *TypeData; // canHaveCoerceToType()
   union {
 llvm::Type *PaddingType; // canHavePaddingType()
 llvm::Type *UnpaddedCoerceAndExpandType; // isCoerceAndExpand()
   };
   union {
-unsigned DirectOffset; // isDirect() || isExtend()
-unsigned IndirectAlign;// isIndirect()
-unsigned AllocaFieldIndex; // isInAlloca()
+llvm::StructType *ExtendSeq; // isCoerceAndExpand()
+unsigned DirectOffset;   // isDirect() || isExtend()
+unsigned IndirectAlign;  // isIndirect()
+unsigned AllocaFieldIndex;   // isInAlloca()
   };
   Kind TheKind;
   bool PaddingInReg : 1;
@@ -110,13 +115,16 @@
 UnpaddedCoerceAndExpandType = T;
   }
 
-  ABIArgInfo(Kind K)
-  : TheKind(K), PaddingInReg(false), InReg(false) {
+  void setExtendSet(llvm::StructType *ES) {
+ 

[PATCH] D48589: [WIP] [CodeGen] Allow specifying Extend to CoerceAndExpand

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 added inline comments.



Comment at: include/clang/CodeGen/CGFunctionInfo.h:475
 
+static_assert(std::is_trivially_copyable::value,
+"ABIArgInfo must be trivially copyable as it is embedded as trailing "

I think this is the right trait here. I spent too much time debugging this :)


https://reviews.llvm.org/D48589



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits