yaxunl added a comment. In https://reviews.llvm.org/D31210#707014, @scchan wrote:
> In https://reviews.llvm.org/D31210#706955, @yaxunl wrote: > > > In https://reviews.llvm.org/D31210#706890, @kzhuravl wrote: > > > > > In https://reviews.llvm.org/D31210#706880, @rampitec wrote: > > > > > > > I'm concerned about the default address space to be 64 bit. It would > > > > move alloca into generic address space effectively making private > > > > address to be 64 bit. > > > > This may have very undesirable performance implications, like address > > > > arithmetic can become expensive 64 bit and only be truncated at load or > > > > store. > > > > I realize you will use addrspacecast on an alloca's value, though I'm > > > > not sure that is sufficient to mitigate performance hit. > > > > I believe such change shall not be made without a good performance > > > > comparison with the feature enabled, provided the very likely > > > > performance issues. > > > > > > > > > Did not we want to use this: > > > http://lists.llvm.org/pipermail/llvm-dev/2017-March/111199.html and use > > > non-0 for our allocas? > > > > > > Our final goal is to let alloca return private pointer. The Clang changes > > are mostly common whether alloca returns generic pointer or private > > pointer. Actually to be able to test the above patch we need to get the > > changes in Clang done first. > > > The goal for this is mainly to bring the mapping closer to nvptx? Our goal is to be able to support both OpenCL and C++-based kernel languages without degrading OpenCL's performance. To achieve that goal alloca returning private pointer may be necessary. https://reviews.llvm.org/D31210 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
