This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp4 03/14] nvptx: expand support for address spaces



On Tue, 20 Oct 2015, Bernd Schmidt wrote:

> On 10/20/2015 08:34 PM, Alexander Monakov wrote:
> > This allows to emit decls in 'shared' memory from the middle-end.
> >
> >  * config/nvptx/nvptx.c (nvptx_legitimate_address_p): Adjust prototype.
> >          (nvptx_section_for_decl): If type of decl has a specific address
> >          space, return it.
> >          (nvptx_addr_space_from_address): Ditto.
> >          (TARGET_ADDR_SPACE_POINTER_MODE): Define.
> >          (TARGET_ADDR_SPACE_ADDRESS_MODE): Ditto.
> >          (TARGET_ADDR_SPACE_SUBSET_P): Ditto.
> >          (TARGET_ADDR_SPACE_CONVERT): Ditto.
> >          (TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P): Ditto.
> 
> Not a fan of this I'm afraid. I used to have address space support in the
> nvptx backend, but the middle-end was too broken for it to work, so I made
> nvptx deal with all the address space complications internally. Is there a
> reason why this approach can't work for what you want to do? (Also, where are
> you using this?)

It is used in patch 06/14, to copy omp_data_o to shared memory.  I don't see
any other sane approach.  Note that patch 06/14 itself will need to be cleaned
up, to use a target hook in pass_late_omp_lower as I imagine.  I expect there
will be other instances where we'll need to place something into ptx shared
memory from the middle end, so having something readily usable without much
churn would be nice.

Thanks.
Alexander


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]