[PATCH] D31210: [AMDGPU] Add new address space mapping

[Yaxun Liu via Phabricator via cfe-commits]

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