Hi Bernd,
I am working on offloading support for OpenMP4, so I'll try to share my vision
of how everything works and answer your questions.
GCC compiles host version of the code (as usual) and dumps Gimple, as it does
for LTO, but for offloading. Gimple IR is stored only for functions/variables
On 11/29/2013 06:12 PM, Jakub Jelinek wrote:
> On Fri, Nov 29, 2013 at 06:07:38PM +0100, Bernd Schmidt wrote:
>> By what mechanism do you choose? This is unclear to me from what I've
>> seen. Does this involve user action, and what's the advantage of doing
>> it this way?
>
> See the 3 threads I'v
On Fri, Nov 29, 2013 at 4:03 PM, Jakub Jelinek wrote:
> On Fri, Nov 29, 2013 at 01:36:48PM +0100, Richard Biener wrote:
>> > Thoughts, comments? Does anyone have a good name for these accelerator
>> > targets or output targets, something that avoids the overloaded word
>> > "target" (I was thinkin
On Fri, Nov 29, 2013 at 06:07:38PM +0100, Bernd Schmidt wrote:
> By what mechanism do you choose? This is unclear to me from what I've
> seen. Does this involve user action, and what's the advantage of doing
> it this way?
See the 3 threads I've mentioned. The compiler would know the list of
avai
On 11/29/2013 06:03 PM, Jakub Jelinek wrote:
> On Fri, Nov 29, 2013 at 05:57:25PM +0100, Bernd Schmidt wrote:
>> On 11/29/2013 04:16 PM, Jakub Jelinek wrote:
>>> As you want to dump the GIMPLE IL right out of ~ IPA stage, it should in
>>> theory be target independent, so it is undesirable to emit i
On Fri, Nov 29, 2013 at 05:57:25PM +0100, Bernd Schmidt wrote:
> On 11/29/2013 04:16 PM, Jakub Jelinek wrote:
> > As you want to dump the GIMPLE IL right out of ~ IPA stage, it should in
> > theory be target independent, so it is undesirable to emit it several times
> > for each offloading target.
On 11/29/2013 04:16 PM, Jakub Jelinek wrote:
> As you want to dump the GIMPLE IL right out of ~ IPA stage, it should in
> theory be target independent, so it is undesirable to emit it several times
> for each offloading target.
That's not what happens. It's just partitioned into disjoint sets, one
On Fri, Nov 29, 2013 at 01:17:56PM +0100, Bernd Schmidt wrote:
> We've been working on similar patches for our OpenACC project. The goal
> is to have functions generated during omp-low that will ultimately
> execute on a ptx target, write them out using LTO infrastructure and
> read them back in us
On Fri, Nov 29, 2013 at 01:36:48PM +0100, Richard Biener wrote:
> > Thoughts, comments? Does anyone have a good name for these accelerator
> > targets or output targets, something that avoids the overloaded word
> > "target" (I was thinking "destination machine" maybe)?
I think offload is best wor
On 11/29/2013 02:05 PM, Kirill Yukhin wrote:
> On 29 Nov 13:17, Bernd Schmidt wrote:
>> 5. There's a new DECL_TARGET which refers to this list of target
>> machines. It's set when creating a child function from e.g. "#pragma acc
>> parallel"
> Actually, I do not understand, what term `target machin
Hello Bernd,
On 29 Nov 13:17, Bernd Schmidt wrote:
> 5. There's a new DECL_TARGET which refers to this list of target
> machines. It's set when creating a child function from e.g. "#pragma acc
> parallel"
Actually, I do not understand, what term `target machine' means here.
Are you talking about
On Fri, Nov 29, 2013 at 1:50 PM, Bernd Schmidt wrote:
> On 11/29/2013 01:36 PM, Richard Biener wrote:
>> Note that we (SUSE/AMD) sofar think we can go an easier route, not
>> adding a real backend that targets HSAIL/BRIG but instead use a
>> custom GIMPLE SSA -> HSAIL/BRIG translator (including a
On 11/29/2013 01:36 PM, Richard Biener wrote:
> Note that we (SUSE/AMD) sofar think we can go an easier route, not
> adding a real backend that targets HSAIL/BRIG but instead use a
> custom GIMPLE SSA -> HSAIL/BRIG translator (including a SSA
> based register allocator). Which if course simplifies
On Fri, Nov 29, 2013 at 1:17 PM, Bernd Schmidt wrote:
> On 11/20/2013 10:36 AM, Jakub Jelinek wrote:
>> On Wed, Nov 20, 2013 at 10:34:30AM +0100, Richard Biener wrote:
>>> On Tue, Nov 19, 2013 at 10:58 AM, Ilya Tocar
>>> wrote:
On 14 Nov 11:27, Richard Biener wrote:
>> + /* Set when sy
On 11/20/2013 10:36 AM, Jakub Jelinek wrote:
> On Wed, Nov 20, 2013 at 10:34:30AM +0100, Richard Biener wrote:
>> On Tue, Nov 19, 2013 at 10:58 AM, Ilya Tocar wrote:
>>> On 14 Nov 11:27, Richard Biener wrote:
> + /* Set when symbol needs to be dumped for lto/offloading. */
> + unsigned
On Mon, Nov 25, 2013 at 05:13:25PM +0100, Thomas Schwinge wrote:
> > --- a/gcc/cgraphunit.c
> > +++ b/gcc/cgraphunit.c
> > @@ -2019,7 +2019,18 @@ ipa_passes (void)
> > passes->all_lto_gen_passes);
> >
> >if (!in_lto_p)
> > -ipa_write_summaries ();
> > +{
> >
Hi!
Just some suggestion related to terminology.
On Tue, 19 Nov 2013 13:58:29 +0400, Ilya Tocar wrote:
> On 14 Nov 11:27, Richard Biener wrote:
> > > + /* Set when symbol needs to be dumped for lto/offloading. */
> > > + unsigned need_dump : 1;
> > > +
> >
> > That's very non-descriptive.
On Wed, Nov 20, 2013 at 10:34:30AM +0100, Richard Biener wrote:
> On Tue, Nov 19, 2013 at 10:58 AM, Ilya Tocar wrote:
> > On 14 Nov 11:27, Richard Biener wrote:
> >> > + /* Set when symbol needs to be dumped for lto/offloading. */
> >> > + unsigned need_dump : 1;
> >> > +
> >>
> >> That's very
On Tue, Nov 19, 2013 at 10:58 AM, Ilya Tocar wrote:
> On 14 Nov 11:27, Richard Biener wrote:
>> > + /* Set when symbol needs to be dumped for lto/offloading. */
>> > + unsigned need_dump : 1;
>> > +
>>
>> That's very non-descriptive. What's "offloading"? But yes, something
>> like this is wha
On 14 Nov 11:27, Richard Biener wrote:
> > + /* Set when symbol needs to be dumped for lto/offloading. */
> > + unsigned need_dump : 1;
> > +
>
> That's very non-descriptive. What's "offloading"? But yes, something
> like this is what I was asking for.
I've changed it into:
Set when symbol n
On Thu, Nov 14, 2013 at 10:52 AM, Ilya Tocar wrote:
> On 18 Oct 13:30, Richard Biener wrote:
>> Certainly better than the first version. Jakub should decide for the branch
>> and eventually Honza for the merge to trunk. It still looks somewhat
>> hackish,
>> but I suppose that's because we don'
On 18 Oct 13:30, Richard Biener wrote:
> Certainly better than the first version. Jakub should decide for the branch
> and eventually Honza for the merge to trunk. It still looks somewhat hackish,
> but I suppose that's because we don't have a LTO-state object where we
> can encapsulate all this.
On Thu, Oct 3, 2013 at 6:05 PM, Ilya Tocar wrote:
> On 26 Sep 21:21, Ilya Tocar wrote:
>> On 25 Sep 15:48, Richard Biener wrote:
>> > On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar
>> > wrote:
>> > > On 24 Sep 11:02, Richard Biener wrote:
>> > >> On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
>> > >
Ping.
On 09 Oct 19:12, Ilya Tocar wrote:
> Ping.
>
> On 03 Oct 20:05, Ilya Tocar wrote:
> > On 26 Sep 21:21, Ilya Tocar wrote:
> > > On 25 Sep 15:48, Richard Biener wrote:
> > > > On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar
> > > > wrote:
> > > > > On 24 Sep 11:02, Richard Biener wrote:
> > > >
Ping.
On 03 Oct 20:05, Ilya Tocar wrote:
> On 26 Sep 21:21, Ilya Tocar wrote:
> > On 25 Sep 15:48, Richard Biener wrote:
> > > On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar
> > > wrote:
> > > > On 24 Sep 11:02, Richard Biener wrote:
> > > >> On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
> > > >> w
On 26 Sep 21:21, Ilya Tocar wrote:
> On 25 Sep 15:48, Richard Biener wrote:
> > On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar wrote:
> > > On 24 Sep 11:02, Richard Biener wrote:
> > >> On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
> > >> wrote:
> > >> thus consider assigning the section
> > >> name
26 matches
Mail list logo
