rjmccall added inline comments.

================
Comment at: clang/lib/CodeGen/CGVTables.cpp:693
     return Int32Ty;
-  return Int8PtrTy;
+  return GlobalsInt8PtrTy;
 }
----------------
bjope wrote:
> I noticed that we have some old fixes downstream that conflicts with the 
> changes you've made here. I thought that perhaps we could get rid of those 
> now when you've fixed the code upstream.
> 
> Isn't the VTable holding function pointers when not using the relative 
> layout, and then this should be a pointer to the ProgramAddressSpace and not 
> a pointer to the DefaultGlobalsAddressSpace?
> 
> Downstream we've been using a special `FnVoidPtrTy` here. Defined as 
> `FnVoidPtrTy = Int8Ty->getPointerTo(DL.getProgramAddressSpace());`.
> 
It's a mix.  The `type_info` pointer should be in the global address space 
(although it would be forgivable to just use the default address space), the 
top, vbase, and vcall offsets are all `ptrdiff_t`s (presumably the same size as 
the default address space), and the virtual functions are function pointers.  
If we're going to support a target where those can be different sizes, we 
probably need to start computing a byte layout of the v-table and doing byte 
GEPs into it, because our current IR patterns are naively assuming the 
components are all the same size.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153092

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

Reply via email to