On 18 Jun 16:22, Bernd Schmidt wrote:
What I think you need to do is
For the first compiler:
--enable-as-accelerator-for=x86_64-pc-linux-gnu
--target=x86_64-intelmic-linux-gnu --prefix=/somewhere
No --enable-accelerator options at all. This should work, if it
doesn't let me know what you
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx (with some additional changes to allow ptx builds
On 07 Jul 17:03, Bernd Schmidt wrote:
Is libgomp the only problematic one? (Does the accel compiler even
need one?) It seems to be installed in /usr/lib rather than in a
gcc-specific directory, which is a little surprising to me. It may
be necessary to give the accel compiler a different
On 23 Jul 16:16, Bernd Schmidt wrote:
Here's the latest version, which fixes some more issues and removes
things that are now unnecessary. Configure scripts and toplevel
autogenned stuff is left out and must be regenerated.
Are you OK with me installing this on gomp-4_0-branch? If there's
On 23 Jul 14:51, Bernd Schmidt wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00616.html
On 06/06/2014 05:07 PM, Bernd Schmidt wrote:
There's a problem when offloading from a compiler for one target machine
to another: the machine specific options don't necessarily match. This
In gcc/configure.ac:
AC_SUBST(enable_accelerator)
offload_targets=`echo $offload_targets | sed -e 's#,#:#'`
AC_DEFINE_UNQUOTED(OFFLOAD_TARGETS, $offload_targets,
Looks like, it should be: sed -e 's#,#:#g'
-- Ilya
Hi,
On 11 Nov 08:10, Jakub Jelinek wrote:
For the middle-end and libgomp changes, can you talk to the Intel folks to
update their git branch to latest trunk (so that you have the nvptx bits in
there) and send middle-end and libgomp diffs against that?
As far as I remember, most of the changes
On 06 Nov 19:21, Jakub Jelinek wrote:
I'm still seeing various unhandled malloc failures, e.g.:
...
would crash if malloc returns NULL. Similarly for realloc:
Fixed in the branch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=534b201fadf0af05ca509dc3f8e13ef26ee719a2
Also, I see you heavily
On 12 Nov 15:34, Richard Biener wrote:
Seems like Vlad introduced the conflicting type with
Okay, we're going to test our changes with patch in the bottom applied
both to kyukhin/gomp4-offload and trunk.
* gcc/lra-lives.c (struct bb_data): Rename to ...
(struct
Hi,
I committed a patch from Dominique d'Humieres to restore bootsrap broken by
our offloading patches.
Thanks,
-- Ilya
2014-11-13 Dominique Dhumieres domi...@lps.ens.fr
PR bootstrap/63853
gcc/
* gcc.c (handle_foffload_option): Replace strchrnul with strchr.
*
Hi,
This patch fixes offloading from dlopened libraries, part 1 is for libgomp and
part 2 is for intelmic plugin (it's not finished yet).
How it works:
When a library is loaded it calls GOMP_offload_register as usually.
At this time some devices may already be initialized, and some may be not.
libgomp/
* libgomp.map (GOMP_4.0.1): Add GOMP_offload_unregister.
* libgomp_target.h (struct mapping_table): Replace with addr_pair.
* target.c (struct gomp_device_descr): Remove register_image_func,
get_table_func. Add load_image_func, unload_image_func.
Resending to gcc-patches@gcc.gnu.org
Hi,
This patch fixes recent regressions in libgomp testsuite:
https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00343.html
They are reproducible only with ld from trunk, ld 2.24 works fine.
When GCC emits sections with offload IR, it should not emit
On 14 Nov 08:46, H.J. Lu wrote:
What happens when -flto is used on command line? Will we
generate both LTO IR and offload IR?
Right.
I'm not sure whether we should make slim objects in case of LTO + offload IR...
-- Ilya
On 14 Nov 09:01, H.J. Lu wrote:
On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin iver...@gmail.com wrote:
On 14 Nov 08:46, H.J. Lu wrote:
What happens when -flto is used on command line? Will we
generate both LTO IR and offload IR?
Right.
I'm not sure whether we should make slim
On 14 Nov 09:11, H.J. Lu wrote:
On Fri, Nov 14, 2014 at 9:08 AM, Ilya Verbin iver...@gmail.com wrote:
On 14 Nov 09:01, H.J. Lu wrote:
On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin iver...@gmail.com wrote:
On 14 Nov 08:46, H.J. Lu wrote:
What happens when -flto is used on command line
And here is the second part, which implements GOMP_OFFLOAD_[un]load_image in
the plugin.
Unfortunately so far unloading for libs is not implemented in liboffloadmic, but
I believe that this patch is better than the current code.
Tested with multiple dso's and on multiple emulated devices (as
Hi,
This patch disables the generation of sections with offload IR and offload
tables by default, when a compiler is configured without
--enable-offload-targets= .
Bootsrap and regtesting in progress, OK after it finished?
-- Ilya
PR regression/63868
gcc/
* cgraph.c
Hi,
On 21 Nov 19:19, Bernd Edlinger wrote:
so, did you really regenerate Makefile.in in that patch, or am I missing
something ?
You're right. This patch was rebased so many times, that we may forget to
regenerate it before committing.
Do you plan to submit any patch for Makefile.in?
Or
Hi Jakub!
On Fri, 21 Nov 2014 21:44:40, Ilya Verbin wrote:
You're right. This patch was rebased so many times, that we may forget to
regenerate it before committing.
Build with liboffloadmic passed. OK for trunk?
-- Ilya
* Makefile.in: Regenerate.
diff --git a/Makefile.in b
Hi,
'#pragma omp critical (name)' can be placed in the function, marked
with '#pragma omp declare target', in this case the corresponding node
should be marked as offloadable too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
-- Ilya
gcc/
* omp-low.c
On 21 Nov 2014, at 23:36, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Nov 21, 2014 at 11:19:26PM +0300, Ilya Verbin wrote:
Hi,
'#pragma omp critical (name)' can be placed in the function, marked
with '#pragma omp declare target', in this case the corresponding node
should be marked
On 22 Nov 2014, at 00:11, H.J. Lu hjl.to...@gmail.com wrote:
Have you fixed the offloading issue with binutils 2.25?
No, I'm still thinking how to make a patch better than the former... Probably
will send it on Monday. (Regressions in make check disappeared after disabling
offload IR in
On 17 Nov 10:57, Richard Biener wrote:
On Fri, Nov 14, 2014 at 6:08 PM, Ilya Verbin iver...@gmail.com wrote:
On 14 Nov 09:01, H.J. Lu wrote:
On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin iver...@gmail.com wrote:
On 14 Nov 08:46, H.J. Lu wrote:
What happens when -flto is used on command
On 25 Nov 10:51, Richard Biener wrote:
In the patch adding flag_generate_offload sounds like a good solution,
I didn't like emitting fat LTO objects unconditionally just because we
offload.
Here is updated patch. Bootstrap and make check passed on i686-linux and
x86_64-linux. Tests with
On 27 Nov 16:00, Richard Biener wrote:
On Thu, Nov 27, 2014 at 2:31 PM, Ilya Verbin iver...@gmail.com wrote:
On 25 Nov 10:51, Richard Biener wrote:
In the patch adding flag_generate_offload sounds like a good solution,
I didn't like emitting fat LTO objects unconditionally just because we
On 21 Nov 21:36, Jakub Jelinek wrote:
On Fri, Nov 21, 2014 at 11:19:26PM +0300, Ilya Verbin wrote:
'#pragma omp critical (name)' can be placed in the function, marked
with '#pragma omp declare target', in this case the corresponding node
should be marked as offloadable too.
Bootstrapped
On 11 Oct 18:49, Ilya Verbin wrote:
(run_gcc): Outline options handling into the new functions:
find_and_merge_options, append_compiler_options, append_linker_options.
...
@@ -625,18 +893,13 @@ run_gcc (unsigned argc, char *argv[])
/* Look at saved options in the IL files
(after everything has been reviewed)?
2014-09-26 Bernd Schmidt ber...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
Ilya Verbin ilya.ver...@intel.com
Andrey Turetskiy andrey.turets...@intel.com
* configure: Regenerate
Hi,
I also rebased and updated our branch:
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload
It contains fixes for the issues, mentioned in Offloading not relocatable.
https://gcc.gnu.org/wiki/Offloading was updated accordingly.
-- Ilya
referenced_from_other_partition_p and
reachable_from_other_partition_p unchanged, then used_from_other_partition will
have incorrect value for target regions, but the offload compiler will just
ignore it. Which approach is better?
Anyway, now it's bootstrapped and regtested on i686-linux and x86_64-linux.
2014-09-27 Ilya
On 29 Sep 03:10, Jan Hubicka wrote:
dump for me implied debug dump. LTO is usually called streaming, so prehaps
need_lto_stremaing?
Fixed.
+initialize_offload (void)
Perhaps have_offload_p? Nothing is initialized here...
The next patch will add some initialization to this function. And
Ilya Verbin ilya.ver...@intel.com
Bernd Schmidt ber...@codesourcery.com
Andrey Turetskiy andrey.turets...@intel.com
Michael Zolotukhin michael.v.zolotuk...@intel.com
gcc/
* Makefile.in (GTFILES): Add omp-low.h to list of GC files.
* cgraphunit.c
On 26 Sep 22:02, Joseph S. Myers wrote:
Any patch adding new configure options needs to add documentation of the
semantics of those options in install.texi. I see no such documentation
in this patch.
Done.
On 30 Sep 13:16, Thomas Schwinge wrote:
Doesn't that comment belong to
On 30 Sep 13:40, Thomas Schwinge wrote:
As just discussed for the libgcc changes in
http://news.gmane.org/find-root.php?message_id=%3C87d2ad73ze.fsf%40schwinge.name%3E,
just some suggestions regarding the terminology, where I think that the
term »target« might be confusing in comments or
) into the new host's
object file.
Bootstrapped and regtested on top of patch 3. Is it OK for trunk?
Thanks,
-- Ilya
2014-10-02 Ilya Verbin ilya.ver...@intel.com
Bernd Schmidt ber...@codesourcery.com
Andrey Turetskiy andrey.turets...@intel.com
Michael Zolotukhin
Hello,
This patch adds plugin support to libgomp, as well as memory mapping and
interaction with target devices through plugin's interface.
Bootstrapped and regtested on top of patch 4. Is it OK for trunk?
Thanks,
-- Ilya
2014-10-06 Jakub Jelinek ja...@redhat.com
Ilya Verbin
On 07 Oct 15:06, Jakub Jelinek wrote:
Still have issues with the non-installed testing.
The idea was that the offload compiler should be installed.
If I add
-B /usr/src/gcc-git/objinst/usr/local/lib/gcc/x86_64-pc-linux-gnu/5.0.0/ \
-B
On 07 Oct 16:30, Jakub Jelinek wrote:
Another thing I've noticed, when target-1.exe is built, there are tons of
sections that IMHO should have been stripped away:
Could you please re-checkout the branch? I fixed this issue a week ago.
Thanks,
-- Ilya
On 07 Oct 16:30, Jakub Jelinek wrote:
I think it is useful, doesn't have to be in the initial checkin, but I'd
certainly prefer if from the (optional) --enable-offload-target argument
it would figure out everything it needs to add for testing.
And, if mkoffload isn't flexible enough to be
I rebased and updated kyukhin/gomp4-offload branch.
It contains renaming of sections/symbols and fixes the cleanup of temporary
directories in the offload emulator.
On 07 Oct 21:40, Jakub Jelinek wrote:
One more thing, I've noticed that running target-1.exe testcase also leaves
On 08 Oct 12:26, Jakub Jelinek wrote:
On Thu, Oct 02, 2014 at 07:14:57PM +0400, Ilya Verbin wrote:
@@ -1296,6 +1297,9 @@ static const char *const standard_startfile_prefix_2
relative to the driver. */
static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX
On 09 Oct 16:07, Ilya Verbin wrote:
+ /* By default linker does not discard .gnu.offload_lto_* sections.
*/
+ const char *linker_script = make_temp_file (_linker_script.x);
+ FILE *stream = fopen (linker_script, w);
+ if (!stream)
+ fatal_error (fopen %s: %m
/gomp4-offload branch is updated correspondingly.
Thanks,
-- Ilya
2014-10-11 Bernd Schmidt ber...@codesourcery.com
Andrey Turetskiy andrey.turets...@intel.com
Ilya Verbin ilya.ver...@intel.com
gcc/
* common.opt (foffload, foffload-abi): New options
On 13 Oct 12:19, Jakub Jelinek wrote:
But I'd like to understand why is this one needed.
Why should the compilers care? Aggregates layout and alignment of
integral/floating types must match between host and offload compilers, sure,
but isn't that something streamed already in the LTO
On 10 Oct 19:00, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 09:51:02AM -0700, Cary Coutant wrote:
The linker already has a --strip-lto-sections option, and it's on by
default. I'll approve a patch that modifies gold to recognize
.gnu.offload_lto.* sections as part of --strip-lto-sections.
On 14 Oct 11:40, Jakub Jelinek wrote:
My preference would be to add the | SECTION_EXCLUDE unconditionally, and
instead guard the
if (flags SECTION_EXCLUDE)
*f++ = 'e';
in varasm.c (default_elf_asm_named_section). The only other user of
SECTION_EXCLUDE seems to be -gsplit-dwarf right
.pdf
Thanks,
-- Ilya
2014-10-15 Andrey Turetskiy andrey.turets...@intel.com
Ilya Verbin ilya.ver...@intel.com
Kirill Yukhin kirill.yuk...@intel.com
Ilya Tocar ilya.to...@intel.com
libgomp/
* testsuite/lib/libgomp.exp
On 15 Oct 17:05, Jakub Jelinek wrote:
This patch adds all examples with '#pragma omp target' from [1] to libgomp
testsuite. Without an accelerator or emulator, these tests are UNSUPPORTED.
Why? Most of the tests should work just fine with host fallback.
Yeah, from Examples 4.0.1 I'm
On 15 Oct 16:38, Jakub Jelinek wrote:
Done. But it turned out that the gcc_GAS_CHECK_FEATURE from
gcc/configure.ac:
gcc_GAS_CHECK_FEATURE([.section with e], gcc_cv_as_section_has_e,
[2,22,51],,
[.section foo1,e
.byte 0,0,0,0])
does not work properly. Maybe it works on
On 15 Oct 17:35, Jakub Jelinek wrote:
But we do want to test them with host fallback, which those lines preclude.
Just a single dg-require-effective-target offload_device guarded test (which
there necessarily is, e.g. the 57.* ones) should be sufficient for your
purposes (if you want to diff
On 17 Oct 16:14, Jakub Jelinek wrote:
-volatile int v;
+volatile int v = 0;
Why?
Ok, I'll revert it back.
--- a/libgomp/testsuite/libgomp.c/target-7.c
+++ b/libgomp/testsuite/libgomp.c/target-7.c
@@ -1,7 +1,9 @@
+// { dg-require-effective-target offload_device }
+
Why? The
On 17 Oct 17:10, Jakub Jelinek wrote:
On Fri, Oct 17, 2014 at 06:58:17PM +0400, Ilya Verbin wrote:
Here in the original test you have:
#pragma omp target if (v = 1)
if (omp_get_level () != 0 || (f !omp_is_initial_device ()))
abort ();
#pragma omp target device (d) if (v
On 17 Oct 17:18, Jakub Jelinek wrote:
On Fri, Oct 17, 2014 at 07:17:31PM +0400, Ilya Verbin wrote:
On 17 Oct 17:10, Jakub Jelinek wrote:
Well, there is no need to remove them, just the || (f
!omp_is_initial_device ())
should be dropped from target regions without device (d) on them
2014-10-19 Ilya Verbin ilya.ver...@intel.com
gcc/
* configure: Regenerate.
* configure.ac: Move the test for section attribute specifier e in GAS
out to all i[34567]86-*-* | x86_64-*-* targets and add --fatal-warnings.
* langhooks.c (lhd_begin_section): Set
On 15 Oct 16:23, Richard Biener wrote:
+static bool
+initialize_offload (void)
+{
+ bool have_offload = false;
+ struct cgraph_node *node;
+ struct varpool_node *vnode;
+
+ FOR_EACH_DEFINED_FUNCTION (node)
+if (lookup_attribute (omp declare target, DECL_ATTRIBUTES
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target gcc read decls from lto and target_lto sections
On 27 Mar 15:02, Jakub Jelinek wrote:
The tables need to be created before IPA, that way it really shouldn't
matter in what order you emit them. E.g. the outlined target functions
could be added to the table during ompexp pass which actually creates the
outlined functions, the vars need to be
On 27 Mar 17:16, Jakub Jelinek wrote:
Which is why the table created for host by the ompexp pass should be
streamed into the target_lto sections (marked specially somehow, special
attribute or whatever), and then corresponding target table created from
that, rather then created from some
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Shouldn't we just remove __OPENMP_TARGET__ argument from GOMP_target,
since we decided to pass it to
2014-04-03 21:06 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 04/03/2014 06:53 PM, Ilya Verbin wrote:
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you
2014-04-03 21:28 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 04/03/2014 07:25 PM, Ilya Verbin wrote:
Yes, initially the idea was to use it for look up the right function.
But now each DSO will call GOMP_offload_register, and pass unique
pointer to __OPENMP_TARGET__ (host_table
On 27 Mar 17:16, Jakub Jelinek wrote:
On Thu, Mar 27, 2014 at 08:13:00PM +0400, Ilya Verbin wrote:
On 27 Mar 15:02, Jakub Jelinek wrote:
The tables need to be created before IPA, that way it really shouldn't
matter in what order you emit them. E.g. the outlined target functions
could
On 17 Apr 22:33, Ilya Verbin wrote:
Hi Jakub,
Could you please take a look at this patch? It fixes the ordering issue in
the
tables stated above, and passes all the tests that I have. But I'm not sure
about its correctness from the architectural point of view.
Thanks,
-- Ilya
Ping.
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous version of this patch which didn't try
to use this.
Bernd
This approach does not work
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations where the host will eventually be able to
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host gcc with --enable-offload-targets
as
2014-05-27 15:15 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
Do I understand correctly that you recommend to build our offload gcc
manually, rather than during configure/make?
Well, configure/make it separately - build and install it first
On 10 Jun 15:52, Bernd Schmidt wrote:
On 04/17/2014 08:33 PM, Ilya Verbin wrote:
+{
+ /* Collect all omp-target global variables to offload_vars, if they have
not
+ been gathered earlier by input_offload_tables. */
+ if (vec_safe_is_empty (offload_vars))
What if a variable
Hello Bernd,
On 28 Feb 17:21, Bernd Schmidt wrote:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it
into locations where the host will eventually be able to find it.
On 17 Jun 21:22, Bernd Schmidt wrote:
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
I don't get this part of the plan. Where a host compiler will look for
mkoffloads?
E.g., first I configure/make/install the target gcc and corresponding
mkoffload with the following options:
--enable
Adding gcc-patches.
Hi Bernd,
The table is used in libgomp (see my patch [1]), as proposed by Jakub
(see [2]). The idea is that the order of entries in the host and
target tables must be identical. This allows to set up one-to-one
correspondence between host and target addresses.
In my patch
Hi Bernd,
2014/1/27 Bernd Schmidt ber...@codesourcery.com:
Once I worked around this by unsetting the environment variables around this
compiler invocation here, the next problem is exposed - the code tries to
link together files compiled for the target (created by the code quoted
above) and
2014/1/29 Bernd Schmidt ber...@codesourcery.com:
I was worried the answer was going to be something like this. These are
produced by two different compilers/linkers, aren't they? This seems really
fragile to me and a recipe for hard-to-debug silent failures.
Yes.
First we let the driver
2014-01-30 H.J. Lu hjl.to...@gmail.com:
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256rnds2, 0,
IX86_BUILTIN_SHA256RNDS2, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI_V4SI },
^ Is OPTION_MASK_ISA_SSE2 intentional?
Should it be OPTION_MASK_ISA_SHA?
--
H.J.
This
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
However, if we decide to use element-wise host-target address mapping,
there are opportunities to
/ChangeLog.gomp b/libgomp/ChangeLog.gomp
index 8f3da2b..12c0c53 100644
--- a/libgomp/ChangeLog.gomp
+++ b/libgomp/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2014-02-17 Ilya Verbin ilya.ver...@intel.com
+
+ * target.c (gomp_map_vars_existing): Don't update copy_from for the
+ existing mappings.
+
2014-01
2014-02-18 20:25 GMT+04:00 Thomas Schwinge tho...@codesourcery.com:
Sure; this was the consensus, as I understand it. Though, wouldn't it
make sense to also add a test case to a) test for this behavior, and also
b) to document the GCC interpretation of the OpenMP standard in this
case
2014-02-19 20:10 GMT+04:00 Thomas Schwinge tho...@codesourcery.com:
Here is such a libgomp plugin plus the infrastructure for initial support
of non-shared memory host execution. Any comments?
Grüße,
Thomas
This plugin looks good.
I think the function call in GOMP_target also should be
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There were still a number of things in these patches that did not make sense
to me and which I've changed. Let me know if there was a good reason for the
way some of these things were originally done.
* Functions and variables
2014-02-21 19:41 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The problem is that ptx does not have a linker, so we cannot exactly
reproduce what happens on the host side. We have to process all host .o
files in one single invocation of ptx lto1, and produce a single ptx
assembly file,
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
* Functions and variables now go into different tables, otherwise
intermixing between them could be a problem that causes tables to
go out of sync between host and target (imagine one big table being
generated by ptx
On 28 Feb 17:21, Bernd Schmidt wrote:
It would help to see the code you have on the libgomp side, I don't
believe that's been posted yet?
It was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01777.html
And below is the updated version.
---
libgomp/libgomp.map |1 +
2014-03-06 12:47 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
I don't see why you want the array of target descriptors - it would take
some effort to construct, and as far as I can tell it's unnecessary. You
can just pass a pointer to the corresponding descriptor to every
2014-03-06 15:53 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
No. I don't think we need a global constructor for registering
__OPENMP_TARGET_HOST__ - this would unnecessarily bloat crtbegin/crtend. We
also shouldn't need to have the target tables known outside of the image
constructed by
Hi Bernd,
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
---
libgomp/libgomp.map |1 +
libgomp/plugin-host.c | 58 -
libgomp/target.c
2014-03-12 18:12 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
LGTM. Shall I start committing my changes to the branch?
Yes, I think you should commit your changes.
And we will rewrite our part to use the new configure approach.
-- Ilya
/ChangeLog.gomp
@@ -1,3 +1,32 @@
+2014-03-12 Ilya Verbin ilya.ver...@intel.com
+
+ * libgomp.map (GOMP_4.0): Add GOMP_offload_register.
+ * plugin-host.c (device_available): Replace with:
+ (get_num_devices): This.
+ (get_type): New.
+ (offload_register): Ditto
Ping.
2014-03-12 21:56 GMT+04:00 Ilya Verbin iver...@gmail.com:
Hi Thomas,
Here is a new version of this patch (it was discussed in other thread:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00573.html ) with ChangeLog.
Bootstrap and make check passed.
Ok to commit?
-- Ilya
On 17 Mar 16:00, Thomas Schwinge wrote:
GOMP_4.0 {
global:
+ GOMP_offload_register;
GOMP_barrier_cancel;
GOMP_cancel;
GOMP_cancellation_point;
Now that the GOMP_4.0 symbol version is being used in GCC trunk, and will
be in the GCC 4.9 release, can we still add new
Hello,
This patchset would contain target-specific things to support offloading to the
devices with Intel MIC architecture.
Particularly: mkoffload tool, liboffloadmic library and a plugin for libgomp.
-- Ilya
object file that can be
linked in with the host binary. Also the final object contains a constructor
that calls GOMP_offload_register to identify itself at runtime.
Autogenerated files are skipped. Is it ok for trunk?
Thanks,
-- Ilya
2014-10-21 Ilya Verbin ilya.ver...@intel.com
, and it uses
liboffloadmic_target.so.
The plugin builds automatically with liboffloadmic.
Autogenerated files are skipped. Is it ok for trunk?
Thanks,
-- Ilya
2014-10-21 Ilya Verbin ilya.ver...@intel.com
Andrey Turetskiy andrey.turets...@intel.com
liboffloadmic
2014-10-22 1:55 GMT+04:00 Joseph S. Myers jos...@codesourcery.com:
On Tue, 21 Oct 2014, Ilya Verbin wrote:
+#include libgen.h
+#include config.h
+#include system.h
You should never include system headers before config.h because config.h
may define feature test macros
On 22 Oct 09:57, Jakub Jelinek wrote:
On Wed, Oct 22, 2014 at 02:30:44AM +0400, Ilya Verbin wrote:
This mkoffload is expected to be built only with the offload compiler,
which is expected to be configured with
'--enable-as-accelerator-for=... --host=x86_64-*-linux-gnu
--target=x86_64
On 22 Oct 10:54, Jakub Jelinek wrote:
On Tue, Oct 21, 2014 at 09:20:34PM +0400, Ilya Verbin wrote:
This patch contains liboffloadmic library.
It is used by ICC for offloading. The sources are imported from upstream
( https://www.openmprtl.org/sites/default/files/liboffload_oss.tgz
On 22 Oct 11:22, Jakub Jelinek wrote:
On Tue, Oct 21, 2014 at 09:24:13PM +0400, Ilya Verbin wrote:
+ mic_lib_path_new = (char *) malloc ((mic_lib_path ? strlen
(mic_lib_path) : 0)
+ + strlen (ld_lib_path) + 2);
malloc can fail, SIGSEGV in response
On 20 Oct 15:19, Ilya Verbin wrote:
On 15 Oct 16:23, Richard Biener wrote:
+static bool
+initialize_offload (void)
+{
+ bool have_offload = false;
+ struct cgraph_node *node;
+ struct varpool_node *vnode;
+
+ FOR_EACH_DEFINED_FUNCTION (node
On 24 Oct 16:35, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 07:41:12PM +0400, Ilya Verbin wrote:
malloc can fail, SIGSEGV in response to that is not desirable.
Can't you fallback to alloca, or use just alloca, or use alloca
with malloc fallback?
I replaced it with alloca
On 08 Oct 13:08, Jakub Jelinek wrote:
On Mon, Oct 06, 2014 at 07:53:17PM +0400, Ilya Verbin wrote:
libgomp/
* libgomp.map (GOMP_4.0.1): New symbol version.
Add GOMP_offload_register.
* libgomp_target.h: New file.
* splay-tree.h: New file.
* target.c: Include
1 - 100 of 379 matches
Mail list logo
