Re: Partial Offloading (was: [hsa merge 07/10] IPA-HSA pass)

On Thu, Jan 28, 2016 at 12:36:19 +0100, Thomas Schwinge wrote: > I made an attempt to capture the recent discussion (plus my own > ideas/understanding) in this new section: > . Please > change/extend, as required. Thanks for summarizing

Partial Offloading (was: [hsa merge 07/10] IPA-HSA pass)

Hi! > [...] I made an attempt to capture the recent discussion (plus my own ideas/understanding) in this new section: . Please change/extend, as required. Grüße Thomas signature.asc Description: PGP signature

Re: [hsa merge 07/10] IPA-HSA pass

On 01/26/2016 12:41 AM, Jan Hubicka wrote: >> On Mon, Jan 25, 2016 at 04:21:50PM +0100, Martin Liška wrote: >>> On 01/16/2016 11:00 AM, Jan Hubicka wrote: Can't it be represented via explicit REF_ADDR or something like that? Honza >>> >>> Hi. >>> >>> Sure, I've just done a patch

Re: [hsa merge 07/10] IPA-HSA pass

On 01/16/2016 11:00 AM, Jan Hubicka wrote: > Can't it be represented via explicit REF_ADDR or something like that? > > Honza Hi. Sure, I've just done a patch that can do that. However, as we're currently in stage4, that change would probably require explicit permission of a release manager?

Re: [hsa merge 07/10] IPA-HSA pass

On Mon, Jan 25, 2016 at 04:21:50PM +0100, Martin Liška wrote: > On 01/16/2016 11:00 AM, Jan Hubicka wrote: > > Can't it be represented via explicit REF_ADDR or something like that? > > > > Honza > > Hi. > > Sure, I've just done a patch that can do that. However, as we're currently in > stage4,

Re: [hsa merge 07/10] IPA-HSA pass

> On Mon, Jan 25, 2016 at 04:21:50PM +0100, Martin Liška wrote: > > On 01/16/2016 11:00 AM, Jan Hubicka wrote: > > > Can't it be represented via explicit REF_ADDR or something like that? > > > > > > Honza > > > > Hi. > > > > Sure, I've just done a patch that can do that. However, as we're

Re: [hsa merge 07/10] IPA-HSA pass

On Wed, Jan 20, 2016 at 09:53:30PM +0300, Ilya Verbin wrote: > If you're OK with this, I'll install this patch: > > > libgomp/ > * target.c (gomp_get_target_fn_addr): Allow host fallback if target > function wasn't mapped to the device with non-shared memory. Ok, thanks. > diff

Re: [hsa merge 07/10] IPA-HSA pass

On Wed, 20 Jan 2016, Ilya Verbin wrote: > I agree that OpenMP doesn't guarantee that all target regions must be executed > on the device, but in this case a user can't be sure that some library > function > always will offload (because the library might be replaced by fallback > version), > and

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 21:05:47 +0300, Ilya Verbin wrote: > On Fri, Jan 15, 2016 at 17:45:22 +0100, Jakub Jelinek wrote: > > On Fri, Jan 15, 2016 at 07:38:14PM +0300, Ilya Verbin wrote: > > > On Fri, Jan 15, 2016 at 17:09:54 +0100, Jakub Jelinek wrote: > > > > On Fri, Jan 15, 2016 at 05:02:34PM

Re: [hsa merge 07/10] IPA-HSA pass

> On 01/15/2016 10:52 AM, Jan Hubicka wrote: > > Do we really need to look that up in the hsa summary? Why these can not be > > partitioned the > > usual way? > > Hi. > > Yes, it's needed as hsa-brig.c uses host function declaration of a kernel as > a key for libgomp. > That's why we want to

Re: [hsa merge 07/10] IPA-HSA pass

On 01/15/2016 10:52 AM, Jan Hubicka wrote: > Do we really need to look that up in the hsa summary? Why these can not be > partitioned the > usual way? Hi. Yes, it's needed as hsa-brig.c uses host function declaration of a kernel as a key for libgomp. That's why we want to put the pair to a LTO

Re: [hsa merge 07/10] IPA-HSA pass

On 01/14/2016 01:58 PM, Jakub Jelinek wrote: > Does it really need to be enabled whenever in_lto_p? > I mean, if HSA is not configured in, I think the gate should be false too. Sure, it can be removed, change will incorporated in final installed version of the file. Thanks, Martin

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 03:53:23PM +0100, Martin Jambor wrote: > @@ -317,7 +319,7 @@ public: > bool > pass_ipa_hsa::gate (function *) > { > - return hsa_gen_requested_p () || in_lto_p; > + return hsa_gen_requested_p (); > } > > } // anon namespace I actually didn't mean this, I mean more

Re: [hsa merge 07/10] IPA-HSA pass

On Thu, Jan 14, 2016 at 01:58:58PM +0100, Jakub Jelinek wrote: > Otherwise LGTM. > > Jakub Thanks Jakub, I have committed the following patch from Martin Liska that addresses your comments. Martin 2016-01-15 Martin Liska * ipa-hsa.c (process_hsa_functions):

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 05:02:34PM +0100, Martin Jambor wrote: > How do other accelerators cope with the situation when half of the > application is compiled with the accelerator disabled? (Would some of > their calls to GOMP_target_ext lead to abort?) GOMP_target_ext should never abort (unless

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 07:38:14PM +0300, Ilya Verbin wrote: > On Fri, Jan 15, 2016 at 17:09:54 +0100, Jakub Jelinek wrote: > > On Fri, Jan 15, 2016 at 05:02:34PM +0100, Martin Jambor wrote: > > > How do other accelerators cope with the situation when half of the > > > application is compiled with

Re: [hsa merge 07/10] IPA-HSA pass

Hi, On Fri, Jan 15, 2016 at 04:01:49PM +0100, Jakub Jelinek wrote: > On Fri, Jan 15, 2016 at 03:53:23PM +0100, Martin Jambor wrote: > > @@ -317,7 +319,7 @@ public: > > bool > > pass_ipa_hsa::gate (function *) > > { > > - return hsa_gen_requested_p () || in_lto_p; > > + return

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 17:09:54 +0100, Jakub Jelinek wrote: > On Fri, Jan 15, 2016 at 05:02:34PM +0100, Martin Jambor wrote: > > How do other accelerators cope with the situation when half of the > > application is compiled with the accelerator disabled? (Would some of > > their calls to

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 10:19:13PM +0300, Alexander Monakov wrote: > Sorry, can you clarify -- what do you mean by "can't offload"? I meant stuff like setjmp/longjmp, exceptions?, alloca (I know your changes might fix this one), computed goto, non-local goto, and the like, which I believe nvptx

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 17:45:22 +0100, Jakub Jelinek wrote: > On Fri, Jan 15, 2016 at 07:38:14PM +0300, Ilya Verbin wrote: > > On Fri, Jan 15, 2016 at 17:09:54 +0100, Jakub Jelinek wrote: > > > On Fri, Jan 15, 2016 at 05:02:34PM +0100, Martin Jambor wrote: > > > > How do other accelerators cope

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, 15 Jan 2016, Jakub Jelinek wrote: > On Fri, Jan 15, 2016 at 07:38:14PM +0300, Ilya Verbin wrote: > > On Fri, Jan 15, 2016 at 17:09:54 +0100, Jakub Jelinek wrote: > > > On Fri, Jan 15, 2016 at 05:02:34PM +0100, Martin Jambor wrote: > > > > How do other accelerators cope with the situation

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, 15 Jan 2016, Jakub Jelinek wrote: > On Fri, Jan 15, 2016 at 10:19:13PM +0300, Alexander Monakov wrote: > > Sorry, can you clarify -- what do you mean by "can't offload"? > > I meant stuff like setjmp/longjmp, exceptions?, alloca (I know your changes > might fix this one), computed goto,

Re: [hsa merge 07/10] IPA-HSA pass

On Fri, Jan 15, 2016 at 10:46:32PM +0300, Alexander Monakov wrote: > On Fri, 15 Jan 2016, Jakub Jelinek wrote: > > > On Fri, Jan 15, 2016 at 10:19:13PM +0300, Alexander Monakov wrote: > > > Sorry, can you clarify -- what do you mean by "can't offload"? > > > > I meant stuff like setjmp/longjmp,

Re: [hsa merge 07/10] IPA-HSA pass

> 2016-01-13 Martin Liska > Martin Jambor > > * ipa-hsa.c: New file. > * lto-section-in.c (lto_section_name): Add hsa section name. > * lto-streamer.h (lto_section_type): Add hsa section. > * lto-partition.c: Include "hsa.h"

Re: [hsa merge 07/10] IPA-HSA pass

On Wed, Jan 13, 2016 at 06:39:32PM +0100, Martin Jambor wrote: > + cgraph_node *clone = node->create_virtual_clone > + (vec (), NULL, NULL, "hsa"); Nicer formatting would be cgraph_node *clone = node->create_virtual_clone (vec (),

[hsa merge 07/10] IPA-HSA pass

Hi, this patch contains IPA-related changes that we need to bring about for HSA. The patch is a re-post of https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00720.html but so far we have not received any feedback. Let me quote the original accompanying email here for reference: When a target