Re: [gomp4] Offload option handling
On Wed, Sep 17, 2014 at 5:11 PM, Andrey Turetskiy
andrey.turets...@gmail.com wrote:
On Wed, Sep 17, 2014 at 3:19 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
I have no objections to supporting a -ftarget-options switch. I had posted a
patch a while ago that looked somewhat similar, but also contained an
automatic translation step from things like -march=x86_64 to a generic
-foffload-abi=lp64. I still think such a mechanism is desirable.
I'm going to apply your patch on '-ftarget-options' stuff and check if
it works together.
I've applied your option patch on our offload branch (w/o
'-ftarget-options' switch yet) and it seems to be working fine.
However the patch looks a bit unfinished:
@@ -440,7 +554,11 @@ access_check (const char *name, int mode
static char*
prepare_target_image (const char *target, const char *compiler_path,
- unsigned in_argc, char *in_argv[])
+ unsigned in_argc, char *in_argv[],
+ struct cl_decoded_option *compiler_opts,
+ unsigned int compiler_opt_count,
+ struct cl_decoded_option * /*linker_opts */,
+ unsigned int /*linker_opt_count*/)
{
const char **argv;
struct obstack argv_obstack;
@@ -469,8 +587,6 @@ prepare_target_image (const char *target
/* Generate temp file name. */
filename = make_temp_file (.target.o);
- /* -- */
- /* Run gcc for target. */
obstack_init (argv_obstack);
obstack_ptr_grow (argv_obstack, compiler);
obstack_ptr_grow (argv_obstack, -o);
@@ -479,6 +595,8 @@ prepare_target_image (const char *target
for (i = 1; i in_argc; ++i)
if (strncmp (in_argv[i], -fresolution=, sizeof (-fresolution=) - 1))
obstack_ptr_grow (argv_obstack, in_argv[i]);
+
+ append_compiler_options (argv_obstack, compiler_opts, compiler_opt_count);
obstack_ptr_grow (argv_obstack, NULL);
argv = XOBFINISH (argv_obstack, const char **);
argv = XOBFINISH (argv_obstack, char **);
What do you suppose to do with 'linker_opts'?
Do you want to call 'append_linker_options (argv_obstack,
linker_opts, linker_opt_count, false)'? That would explain why you
have 'include_target_options' argument in the function.
--
Best regards,
Andrey Turetskiy
Re: [gomp4] Offload option handling
Hi, This patch (attached) contains the prototype of mechanism for passing options to offload target compiler. If one need to pass additional options for target compiler, one may add option ‘–ftarget-options=target name=target options’ to host compiler (target name can be skipped, that will append specified options for every target). Options preparing takes place in lto-wrapper in several stages: 1. Read (host) options from .gnu.target_lto_.opts section for every object file and merge them as during lto 2. Remove CL_TARGET, CL_DRIVER and CL_LTO options 3. For every offload target: search for option ‘–ftarget-options’ with argument corresponding to target triple, parse it and merge with remained host options Here is an example of option merging: ./install/bin/gcc -fopenmp -c a.c -O0 -mno-sse -ftarget-options==-O2 -msse ./install/bin/gcc -fopenmp -c b.c -O0 -fpack-struct -ftarget-options==-O3 -mavx ./install/bin/gcc -fopenmp a.o b.o After merging at stage 3 we get: -O3 -fpack-struct -ftarget-options==”-O2 –msse” -ftarget-options==”-O3 –mavx” –msse –mavx These options are passed to mkoffload and thus to target compiler. -ftarget-options==”…” itself is ignored by target compiler. However there is an issue: options specified by -ftarget-options are not checked for correctness as usual, so incorrect options inside -ftarget-options==”…” may lead to GCC crashes. Need to investigate possibilities of reusing existing option checks to solve the problem. How does this look? Do you agree with the approach? On Mon, Sep 15, 2014 at 8:22 PM, Ilya Verbin iver...@gmail.com wrote: 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 patch tries to address this. The idea is that since we have two options sections anyway, with different section name prefixes, we can arrange to pass only target-independent options in the omp_ version of the options section. However, some target-specific options (specifically the ones specifying the ABI) need to be preserved somehow, so there's a new target hook for translating them to common a -foffload-* syntax. How does this look? Comments on the approach, and ok for the gomp-4_0-branch? How about passing target-specific options from the command-line? Will it be possible with this approach? We had a patch, that parses options from -foffload-target=target=options and stores them to the environment variable. Now it is obsolete, but I like the idea of having such a user-adjustable options for the accel compilers. https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01242.html -- Ilya -- Best regards, Andrey Turetskiy offload-option-gomp4.patch Description: Binary data
Re: [gomp4] Offload option handling
On Wed, Sep 17, 2014 at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote: I don't like the == in there. Doesn't target name, being a target triplet or something like that, always have to start with alphanumeric character, and options always have to start with -? Thus, can't you decide from the first character after -ftarget-options= whether it is for all or specific target? If the character after = is whitespace or -, it will be for all targets and -ftarget-options=target options form, otherwise it must be -ftarget-options=target name=target options form. Yes, I think it would be better. This patch is just a prototype to show the main idea, so I'd like to hear if you agree with the approach. On Wed, Sep 17, 2014 at 3:19 PM, Bernd Schmidt ber...@codesourcery.com wrote: I have no objections to supporting a -ftarget-options switch. I had posted a patch a while ago that looked somewhat similar, but also contained an automatic translation step from things like -march=x86_64 to a generic -foffload-abi=lp64. I still think such a mechanism is desirable. I'm going to apply your patch on '-ftarget-options' stuff and check if it works together. -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
Ping. On Thu, Sep 4, 2014 at 11:41 AM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Ping. On Tue, Aug 26, 2014 at 10:41 AM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Ping. On Tue, Aug 19, 2014 at 12:45 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello, On 12 Aug 10:58, Andrey Turetskiy wrote: All remarks from https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02166.html are fixed. Updated version of liboffloadmic you can find in GIT branch kyukhin/gomp4-offload: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload. Commit: HEAD~3 (Add liboffloadmic with offloading emulator). Is it ok for trunk now? -- Thanks, K -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
Ping. On Tue, Aug 26, 2014 at 10:41 AM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Ping. On Tue, Aug 19, 2014 at 12:45 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello, On 12 Aug 10:58, Andrey Turetskiy wrote: All remarks from https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02166.html are fixed. Updated version of liboffloadmic you can find in GIT branch kyukhin/gomp4-offload: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload. Commit: HEAD~3 (Add liboffloadmic with offloading emulator). Is it ok for trunk now? -- Thanks, K -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
Ping. On Tue, Aug 19, 2014 at 12:45 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hello, On 12 Aug 10:58, Andrey Turetskiy wrote: All remarks from https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02166.html are fixed. Updated version of liboffloadmic you can find in GIT branch kyukhin/gomp4-offload: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload. Commit: HEAD~3 (Add liboffloadmic with offloading emulator). Is it ok for trunk now? -- Thanks, K -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
All remarks from https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02166.html are fixed. Updated version of liboffloadmic you can find in GIT branch kyukhin/gomp4-offload: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload. Commit: HEAD~3 (Add liboffloadmic with offloading emulator). On Thu, Jul 31, 2014 at 1:00 AM, Joseph S. Myers jos...@codesourcery.com wrote: On Wed, 2 Jul 2014, Andrey Turetskiy wrote: * Don't duplicate the logic for what's a hosted POSIX system; refactor it to a common fragment in config/ (I guess it needs to be a shell script fragment there rather than an actual autoconf macro, since you're using that logic in configure.tgt which is itself such a fragment). I've attached the patch with changes related to the point. Do you mean something like this? Yes, something like that. Obviously post it in its own thread with a subject line explaining what the specific patch does. -- Joseph S. Myers jos...@codesourcery.com -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
Ping. On Mon, Jul 21, 2014 at 1:25 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Ping. On Wed, Jul 2, 2014 at 3:13 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: * Don't duplicate the logic for what's a hosted POSIX system; refactor it to a common fragment in config/ (I guess it needs to be a shell script fragment there rather than an actual autoconf macro, since you're using that logic in configure.tgt which is itself such a fragment). I've attached the patch with changes related to the point. Do you mean something like this? -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
Ping. On Wed, Jul 2, 2014 at 3:13 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: * Don't duplicate the logic for what's a hosted POSIX system; refactor it to a common fragment in config/ (I guess it needs to be a shell script fragment there rather than an actual autoconf macro, since you're using that logic in configure.tgt which is itself such a fragment). I've attached the patch with changes related to the point. Do you mean something like this? -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Re: [PATH] Intel offload library
* Don't duplicate the logic for what's a hosted POSIX system; refactor it to a common fragment in config/ (I guess it needs to be a shell script fragment there rather than an actual autoconf macro, since you're using that logic in configure.tgt which is itself such a fragment). I've attached the patch with changes related to the point. Do you mean something like this? -- Best regards, Andrey Turetskiy liboffload_config.patch Description: Binary data
Re: [RFC][gomp4] Offloading patches (1/3): Add '-fopenmp_target' option
Hi Bernd,
We have some testcases, but they require XeonPhi hardware and a
working libgomp plugin. Our current version of the plugin depends on
some libraries, that are not open-sourced yet, so currently we can’t
share it.
However, you could examine what these patches do, making the following steps:
1) Build GCC with patches:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01484.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01485.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01486.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01896.html
2) Set environment variables (e.g. for two ‘targets’):
export OFFLOAD_TARGET_NAMES=mic:hsail (for now
names don’t really matter)
export OFFLOAD_TARGET_COMPILERS=./gcc:./gcc(use GCC with
patches above as target compiler, because it must support the
-fopenmp_target option)
3) Build any example with #pragma omp target (e.g. see attachment):
./gcc -flto -fopenmp test.c -o test.exe
Options -flto and -fopenmp are necessary for using.
Now you have a binary with target images embedded and tables properly
filled. You can’t run it due to reasons mentioned above, though you
could examine it with objdump/nm/readelf to see new sections and their
content: there will be .offload_image_section with ‘target’ code and
.offload_func_table_section with ‘target’ function table.
On Tue, Jan 21, 2014 at 6:40 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 12/17/2013 12:35 PM, Michael V. Zolotukhin wrote:
Here is a set of patches implementing one more piece of offloading support
in
GCC. These three patches allow to build a host binary with target image
and all
tables embedded. Along with patches for libgomp and libgomp plugin, which
hopefully will be sent soon, that gives a functional and runnable
executable (or
DSO) with actual offloading to MIC.
Do you have a testcase that can be used to see what this does in action?
Bernd
--
Best regards,
Andrey Turetskiy
#define NUM 128
#pragma omp declare target
int cnt = 100;
int calc (int x)
{
return cnt++ * x;
}
#pragma omp end declare target
int main ()
{
int a[NUM];
int i;
cnt = 0;
#pragma omp target update to(cnt)
a[0] = 1;
for (i = 1; i NUM; i++)
a[i] = -a[i-1];
#pragma omp target data map(to: a)
{
for (i = 0; i NUM; i++)
a[i] = 2*a[i];
#pragma omp target
{
for (i = 0; i NUM; i++)
a[i] = calc (a[i]);
}
#pragma omp target update from(a)
}
return 0;
}
Re: [GOMP4] Patch to add option for offloading
Ping On Wed, Dec 18, 2013 at 4:28 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Ping On Fri, Dec 13, 2013 at 3:09 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Hi, I've added option -foffload-target to specify target and options for target compiler for offloading. Please, have a look. -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
Re: [GOMP4] Patch to add option for offloading
Ping On Fri, Dec 13, 2013 at 3:09 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Hi, I've added option -foffload-target to specify target and options for target compiler for offloading. Please, have a look. -- Best regards, Andrey Turetskiy -- Best regards, Andrey Turetskiy
[GOMP4] Patch to add option for offloading
Hi, I've added option -foffload-target to specify target and options for target compiler for offloading. Please, have a look. -- Best regards, Andrey Turetskiy foffload_option.patch Description: Binary data
Re: [PATCH] Replace const_vector with match_operand in sse.md
BTW: Probably, pmulhrsw insn patterns can be merged, too, but this can be a follow-up patch. Please, have a look at patch which merge pmulhrsw patterns. Changelog: 2012-11-13 Andrey Turetskiy andrey.turets...@gmail.com * config/i386/sse.md (*ssse3_avx2_pmulhrswmode3): Merge *avx2_pmulhrswv16hi3 and *ssse3_pmulhrswv8hi3 into one pattern. --- Best regards, Andrey Turetskiy pmulhrsw_merge.patch Description: Binary data
Re: [PATCH] Replace const_vector with match_operand in sse.md
I changed the patch according Uros' remarks. Please, have a look. Changelog: 2012-10-30 Andrey Turetskiy andrey.turets...@gmail.com * config/i386/i386.c (bdesc_args): Rename CODE_FOR_avx2_umulhrswv16hi3 to CODE_FOR_avx2_pmulhrswv16hi3. * config/i386/predicates.md (const1_operand): Extend for vectors. * config/i386/sse.md (ssse3_avx2): Extend. (ssedoublemode): Ditto. (sse2_avx2_uavgmode3): Merge avx2_uavgv32qi3, sse2_uavgv16qi3, avx2_uavgv16hi3 and sse2_uavgv8hi3 into one. (*sse2_avx2_uavgmode3): Merge *avx2_uavgv32qi3, *sse2_uavgv16qi3, *avx2_uavgv16hi3 and *sse2_uavgv8hi3 into one. (PMULHRSW): New. (ssse3_avx2_pmulhrswmode3): Merge avx2_umulhrswv16hi3, ssse3_pmulhrswv8hi3 and ssse3_pmulhrswv4hi3 into one. (*avx2_pmulhrswv16hi3): Replace const_vector with match_operand. (*ssse3_pmulhrswv8hi3): Ditto. (*ssse3_pmulhrswv4hi3): Ditto. --- Best regards, Andrey Turetskiy On Wed, Oct 24, 2012 at 5:36 PM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Oct 24, 2012 at 3:01 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: On Tue, Oct 23, 2012 at 2:45 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Hi, This patch replaces large const_vector constructions with match_operand in sse.md to decrease its size. Is it ok? No, you don't have to touch generic expand machinery. In the expander, use (match_dup X), and declare operands[X] = CONST1_RTX (..some_mode..) in preparation statement. In unnamed patterns, use const1_operand operand predicate. You should extend existing const1_operand in the same way as const0_operand. This approach is not compatible with named insn patterns, which duplicate its functionality as pattern matcher and as an expander. Uros. const_vector_replace.patch Description: Binary data
Re: [PATCH] Replace const_vector with match_operand in sse.md
Thanks for explanation, I understand it.
I fixed issue which you marked. Changelog is unchanged.
---
Best regards,
Andrey Turetskiy
On Tue, Oct 30, 2012 at 7:40 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Oct 30, 2012 at 3:47 PM, Andrey Turetskiy
andrey.turets...@gmail.com wrote:
I changed the patch according Uros' remarks. Please, have a look.
Changelog:
2012-10-30 Andrey Turetskiy andrey.turets...@gmail.com
* config/i386/i386.c (bdesc_args): Rename
CODE_FOR_avx2_umulhrswv16hi3 to
CODE_FOR_avx2_pmulhrswv16hi3.
* config/i386/predicates.md (const1_operand): Extend for vectors.
* config/i386/sse.md (ssse3_avx2): Extend.
(ssedoublemode): Ditto.
(sse2_avx2_uavgmode3): Merge avx2_uavgv32qi3, sse2_uavgv16qi3,
avx2_uavgv16hi3 and sse2_uavgv8hi3 into one.
(*sse2_avx2_uavgmode3): Merge *avx2_uavgv32qi3, *sse2_uavgv16qi3,
*avx2_uavgv16hi3 and *sse2_uavgv8hi3 into one.
(PMULHRSW): New.
(ssse3_avx2_pmulhrswmode3): Merge avx2_umulhrswv16hi3,
ssse3_pmulhrswv8hi3 and ssse3_pmulhrswv4hi3 into one.
(*avx2_pmulhrswv16hi3): Replace const_vector with match_operand.
(*ssse3_pmulhrswv8hi3): Ditto.
(*ssse3_pmulhrswv4hi3): Ditto.
+{
+ ix86_fixup_binary_operands_no_copy (PLUS, MODEmode, operands);
+ operands[3] = CONST1_RTX(MODEmode);
+})
Please put operands[3] initialization before the call to
ix86_f_b_o_n_c. We don't want to pass uninitialized operands around.
+{
+ if (which_alternative == 0
+ (MODEmode == V16QImode
+ || MODEmode == V8HImode))
+return pavgssemodesuffix\t{%2, %0|%0, %2};
+ return vpavgssemodesuffix\t{%2, %1, %0|%0, %1, %2};
+}
+ [(set (attr isa)
+ (if_then_else
+ (match_test which_alternative == 0 (MODEmode ==
V16QImode || MODEmode == V8HImode))
+ (const_string noavx)
+ (const_string avx)))
+ (set (attr prefix_data16)
+(if_then_else (eq_attr isa noavx)
+ (const_string 1)
+ (const_string *)))
+ (set (attr prefix)
+(if_then_else (eq_attr isa noavx)
+ (const_string orig)
+ (const_string vex)))
Uh, oh.
Please note that isa attribute enables or disables the alternative
through enabled attribute. Just change the mode attribute to
sseinsnmode and everything will magically work:
- AVX2 implies AVX, so it enables alternative 1, while disabling
alternative 0 (and vice versa when AVX is disabled through noavx isa
attribute).
- Correct modes are conditionally enabled via VI12_AVX2 iterator
- Base ISA level is enabled via insn predicate (TARGET_SSE2).
You have to track three dependant conditions to calculate how insn
pattern/mode/operand predicate are enabled ;)
Uros,
const_vector_replace.patch
Description: Binary data
Re: [PATCH] Replace const_vector with match_operand in sse.md
Add Uros to Cc. On Tue, Oct 23, 2012 at 2:45 PM, Andrey Turetskiy andrey.turets...@gmail.com wrote: Hi, This patch replaces large const_vector constructions with match_operand in sse.md to decrease its size. Is it ok? Changelog: 2012-10-23 Andrey Turetskiy andrey.turets...@gmail.com * config/i386/avx2intrin.h (_mm256_avg_epu8): Add new operand. (_mm256_avg_epu16): Ditto. (_mm256_mulhrs_epi16): Ditto. * config/i386/emmintrin.h (_mm_avg_epu8): Ditto. (_mm_avg_epu16): Ditto. * config/i386/tmmintrin.h (_mm_mulhrs_epi16): Ditto. (_mm_mulhrs_pi16): Ditto. * config/i386/i386-builtin-types.def DEF_FUNCTION_TYPE (V4HI, V4HI, V4HI, V4HI): New type. * config/i386/i386.c (bdesc_args): Extend builtins types. (ix86_expand_args_builtin): Add support for new types and allow expander to generate const_vector filled with all ones. * config/i386/predicates.md (vector1_operand): New predicate which match const_vector filled with all ones. * config/i386/sse.md (sse2_uavgv16qi3): Replace const_vector with vector1_operand. (sse2_uavgv8hi3): Ditto. (ssse3_pmulhrswv8hi3): Ditto. (ssse3_pmulhrswv4hi3): Ditto. (avx2_uavgv32qi3): Ditto. (avx2_uavgv16hi3): Ditto. (avx2_umulhrswv16hi3): Ditto. --- Best regards, Andrey Turetskiy
