This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4] Some progress on #pragma omp simd
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 12 Jun 2013 19:30:55 +0200
- Subject: Re: [gomp4] Some progress on #pragma omp simd
- References: <20130423135455 dot GN12880 at tucnak dot redhat dot com> <BF230D13CA30DD48930C31D40993300032A37760 at FMSMSX101 dot amr dot corp dot intel dot com> <20130424060117 dot GV12880 at tucnak dot redhat dot com> <20130424062536 dot GW12880 at tucnak dot redhat dot com> <20130424064054 dot GX12880 at tucnak dot redhat dot com> <5178692F dot 2010902 at redhat dot com> <BF230D13CA30DD48930C31D40993300032A39A2B at FMSMSX101 dot amr dot corp dot intel dot com> <517C0B34 dot 3050804 at redhat dot com> <20130427181734 dot GX28963 at tucnak dot redhat dot com> <51B8AE31 dot 7070808 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jun 12, 2013 at 10:21:53AM -0700, Richard Henderson wrote:
> On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> > where simd_uid would be some say integer constant, unique to the simd loop
> > (at least unique within the same function, and perhaps inlining/LTO would
> > need to remap).
>
> If all we need is uniqueness, then perhaps an otherwise unused decl would do?
> We're already prepared to remap those during inlining/LTO...
So the built-ins would take address of this decl, something else?
Then there is the _simduid_ clause (also can hold address of the decl), and
after lowering it lives only in loop structure (so perhaps
remove_unused_locals would need to mark the decls referenced from loop
structure as used?).
> > treat arrays indexed by __builtin_omp.simd_lane (simd_uid) (dot in the name just
> > to make it impossible to be used by users) (or marked with some special
> > hidden attribute or something)
>
> I see
>
> /* This file specifies a list of internal "functions". These functions
> differ from built-in functions in that they have no linkage and cannot
> be called directly by the user. They represent operations that are only
> synthesised by GCC itself.
>
> and think that may be more applicable than adding dots to regular builtins.
I can certainly try to use internal function instead of builtin with dot in
name, will report later if it is possible and how much changes would it
need.
Jakub