On Thu, Sep 19, 2013 at 02:44:30PM +0400, Ilya Verbin wrote:
> Do I understand correctly that GIMPLE IL is target dependent, but we will emit
> the same IL for all targets?
Yes. Some of the target dependencies are required to be inherited from the
host, some can be tolerated (optimization decisio
On 17 Sep 14:12, Jakub Jelinek wrote:
> On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> >
> > Are you sure we have the same IL for all targets and the same targets
> > for all functions? That would certainly simplify things, but you still need
> > a way to tell the target compil
On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin wrote:
> > On 17 Sep 10:12, Richard Biener wrote:
> >> It looks more like a hack ;) It certainly doesn't look scalable to
> >> multiple
> >> target ISAs. You also unconditionally invok
On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin wrote:
> On 17 Sep 10:12, Richard Biener wrote:
>> It looks more like a hack ;) It certainly doesn't look scalable to multiple
>> target ISAs. You also unconditionally invoke the target compiler (well, you
>> invoke the same compiler ...)
>
> Yes, I c
On Tue, Sep 17, 2013 at 03:30:10PM +0400, Ilya Verbin wrote:
> On 17 Sep 10:12, Richard Biener wrote:
> > It looks more like a hack ;) It certainly doesn't look scalable to multiple
> > target ISAs. You also unconditionally invoke the target compiler (well, you
> > invoke the same compiler ...)
>
On 17 Sep 10:12, Richard Biener wrote:
> It looks more like a hack ;) It certainly doesn't look scalable to multiple
> target ISAs. You also unconditionally invoke the target compiler (well, you
> invoke the same compiler ...)
Yes, I currently call the "target" compiler unconditionally, but it c
On Mon, Sep 16, 2013 at 7:14 PM, Ilya Verbin wrote:
> Hi Richard,
>
> On 23 Aug 14:24, Richard Biener wrote:
>> Ilya Verbin wrote:
>> >I'm trying to implement the approach with modified lto-wrapper.
>> >Suppose we have a bytecode of the routine foo, streamed during ompexp
>> >pass into some secti
Hi Richard,
On 23 Aug 14:24, Richard Biener wrote:
> Ilya Verbin wrote:
> >I'm trying to implement the approach with modified lto-wrapper.
> >Suppose we have a bytecode of the routine foo, streamed during ompexp
> >pass into some section, say .gnu.omptarget_foo.
> >In function lto.c:do_whole_prog
Hi Thomas,
> The idea, as we discussed it at the GNU Tools Cauldron's Acceleration
> BoF, is that the host program (for at least some acceleration devices)
> will be responsible for loading the acceleration device's code to the
> device, using some support library that is specific to each accelera
On Tue, Sep 03, 2013 at 10:29:56PM +0400, Michael V. Zolotukhin wrote:
> > The idea, as we discussed it at the GNU Tools Cauldron's Acceleration
> > BoF, is that the host program (for at least some acceleration devices)
> > will be responsible for loading the acceleration device's code to the
> > d
> > Oh, if we just link the target binary as a data section into the host
> > binary, then I see no problems in that, it seems absolutely feasible
> > with the existing infrastructure. I just thought (seemingly it was
> > incorrect) that we're speaking about linking of target code with the
> > hos
Hi!
On Tue, 3 Sep 2013 19:18:01 +0400, "Michael V. Zolotukhin"
wrote:
> > - collect all those target object files from the link, link them together
> > using target compiler driver, and feed back the resulting binary
> > or shared library into the host linking (some magic section in there)
>
> I'd go with .gnu.target_lto* names (i.e. s/.gnu.lto/.gnu.target_lto/
> on the existing LTO section names if they are for the accelerator rather
> than host).
I guess that now we could go with any naming, as it's far from being
finalized.
> I really have almost zero experience with LTO, but I don
On Tue, Sep 03, 2013 at 05:59:35PM +0400, Michael V. Zolotukhin wrote:
> Let's continue this discussion.
>
> Summing up what was said above, I think we need following changes in
> LTO-infrastructure to enable offloading:
> * [in lto_plugin] claim files with .openmp (or whatever
> name) sections
Hi guys,
Let's continue this discussion.
Summing up what was said above, I think we need following changes in
LTO-infrastructure to enable offloading:
* [in lto_plugin] claim files with .openmp (or whatever
name) sections along with files containing .lto sections, as we do now
* [in lto_plugin
On Fri, 2013-08-23 at 13:17 +0200, Jakub Jelinek wrote:
[...]
> Then the question is what the plugin should perform with these sections,
> whether it will compile each input .gnu.target_lto section hunk separately
> (as in non-LTO mode), or with -flto also LTO them together.
[...]
Since plugins ar
On Fri, Aug 23, 2013 at 09:15:14PM +0400, Ilya Verbin wrote:
> On 23 Aug 13:17, Jakub Jelinek wrote:
> > I don't think we should stream into more than one target section.
> > There should be just .gnu.target_lto section (or whatever other suitable
> > name) and should stream into it:
> > 1) all fun
On 23 Aug 13:17, Jakub Jelinek wrote:
> I don't think we should stream into more than one target section.
> There should be just .gnu.target_lto section (or whatever other suitable
> name) and should stream into it:
> 1) all functions and variables with "omp declare target" attribute
> 2) the outli
On Fri, Aug 23, 2013 at 02:24:42PM +0200, Richard Biener wrote:
> >As far as I understood, in addition to the bytecode of foo, we should
> >also stream extra symtab_nodes, and read them somewhere in
> >lto-cgraph.c:input_symtab().
> >This means we should maintain 2 symtabs inside WPA stage - origin
Ilya Verbin wrote:
>Jakub, Richard, Uday,
>Thanks for your answers.
>
>On 15 Aug 20:59, Richard Biener wrote:
>> Alternatively you make lto-wrapper aware of this which means that WPA
>stage would emit extra partitions that it marks for lto-wrapper.
>>
>> That sounds better than another plugin to
On Fri, Aug 23, 2013 at 02:55:27PM +0400, Ilya Verbin wrote:
> I'm trying to implement the approach with modified lto-wrapper.
> Suppose we have a bytecode of the routine foo, streamed during ompexp pass
> into some section, say .gnu.omptarget_foo.
> In function lto.c:do_whole_program_analysis() a
Jakub, Richard, Uday,
Thanks for your answers.
On 15 Aug 20:59, Richard Biener wrote:
> Alternatively you make lto-wrapper aware of this which means that WPA stage
> would emit extra partitions that it marks for lto-wrapper.
>
> That sounds better than another plugin to me. Of course WPA time m
Jakub Jelinek wrote:
>On Thu, Aug 15, 2013 at 05:36:39PM +0400, Ilya Verbin wrote:
>> 2. The second question, regarding #pragma omp target implementation.
>> I'm going to reuse LTO approach in a prototype, that will produce 2
>> binaries - for host and target architectures. Target binary will
>c
On Thu, Aug 15, 2013 at 05:36:39PM +0400, Ilya Verbin wrote:
> 2. The second question, regarding #pragma omp target implementation.
> I'm going to reuse LTO approach in a prototype, that will produce 2
> binaries - for host and target architectures. Target binary will contain
> functions outlined
Hi All,
I'm trying to figure out how LTO infrastructure works on a high level.
I want to make sure that I understand this correctly. Could you please
help me with that?
1. Execution flow. As far as I understood, there are 2 modes of
operation - with/without LTO plugin. Below are the execution
25 matches
Mail list logo
