erichkeane added inline comments.

================
Comment at: clang/include/clang/Basic/Specifiers.h:283
     CC_AArch64VectorCall, // __attribute__((aarch64_vector_pcs))
+    CC_AArch64SVEPcs, // __attribute__((aarch64_sve_pcs))
   };
----------------
aaron.ballman wrote:
> I continue to be concerned with how many custom calling conventions we're 
> adding. We're running out of bits to store them and when we bump up against 
> the next limitation (32 possible calling conventions, this patch brings us up 
> to 20), we're going to lose a significant amount of performance due to extra 
> memory overhead pressure (which, in turn, will greatly reduce our maximum 
> template instantiation depth) with no clear path forward. We've looked into 
> this before and once we hit that 32 calling convention limit, we won't be 
> adding any new calling conventions until we solve the memory pressure problem.
> 
> Are there other alternatives than making a new calling convention? (e.g., can 
> this be handled with a backend pass somehow, or some other implementation 
> strategy?)
> Is this calling convention going to be used often enough to warrant adding 
> it? (e.g., will this be showing up in system headers or other major 
> third-party library headers, or is this a one-off for people trying to eek 
> the last ounce of performance out of a function call?)
I agree with this, our list of calling conventions needs to find a way to get 
smaller, not larger.  our `ExtInfo` is already shocking/frighteningly large use 
of bits with calling conventions taking 5.  IMO, we should reduce this to 4 
bits if at all possible, particularly since we're likely to need more bits in 
the function-type thanks to the C++ committee.

Internally, Ive been fighting pretty hard to keep us from extending this list 
unless at all possible, and I think we need to do so here.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124998

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

Reply via email to