RE: Implement #pragma unroll?
Bingfeng,
to define the pragma you use something like this:
#define REGISTER_TARGET_PRAGMAS()
{
c_register_pragma (0, "unroll_factor",
support_unroll_pragma);
}
such that when you compile a loop like this you get it
unrolled 20 times:
#pragma unroll_factor=20
for(i = 0; i < 40; i++){
m[i]=3;
}
then you have to implement the support_unroll_pragma
function
which in my case I used it to extract the unrolling
factor (in this case 20)
and to insert in the parse tree an intrinsic. Here is
my code:
void
support_unroll_pragma (cpp_reader * pfile
ATTRIBUTE_UNUSED)
{
tree x;
enum cpp_ttype token;
int unroll_factor = 0;
token = pragma_lex (&x);
gcc_assert (token == CPP_EQ);
token = pragma_lex (&x);
gcc_assert (token == CPP_NUMBER);
unroll_factor = TREE_INT_CST_LOW (x);
tree type =
build_function_type_list (void_type_node,
integer_type_node, NULL_TREE);
tree t = build_fn_decl ("__unroll_pragma", type);
enum built_in_function code = DECL_FUNCTION_CODE
(t);
DECL_BUILT_IN_CLASS (t) = BUILT_IN_MD;
TREE_PUBLIC (t) = 1;
DECL_EXTERNAL (t) = 1;
DECL_FUNCTION_CODE (t) =
builtin_line_no("__unroll_pragma");
tree operand = build_int_cst (NULL_TREE,
unroll_factor);
t = build_call_expr (t, 1, operand);
add_stmt (t);
}
trimedia_builtin_line_no generates a call described by
the following pattern:
(define_insn "customop_unroll_pragma"
[(unspec_volatile:SI
[
(match_operand:SI 0
"immediate_operand" "i")
] UNSPEC_unroll_pragma)
]
""
""
)
which in loop-unroll (where you have RTL instructions)
is caught with the
with something like this:
(INSN_P(insn) && recog_memoized(insn) ==
CODE_FOR_customop_unroll_pragma
more or less this is it.
Alex
--- Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Alex, Thanks for your suggestion. What target hook
> do you use for the
> backend function?
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Alex Turjan
> Sent: 29 May 2008 14:45
> To: gcc@gcc.gnu.org
> Subject: RE: Implement #pragma unroll?
>
> Dear Bingfeng,
> Some time ago I had to deal with a similar issue as
> you. Basically I did as follows: I built a backend
> function which catches the unroll pragma and
> replaces
> it with a target assembly intrinsic (which of course
> has to be described in an .md file). After that in
> the
> RTL unroll phase, I analyze loop by loop and connect
> them to the corresponding unrolling intrinsic (which
> as a field contains the unrolling factor, you may
> add
> here extra information which allows you to recognize
> the loop) from where I decide the unrolling factor.
> After that in the RTL unroll phase I remove all the
> unroll intrinsics.
> hope this will help,
> Alex
>
>
>
>
>
>
>
RE: Implement #pragma unroll?
Alex,
Thank you very much. I know REGISTER_TARGET_PRAGMAS interface, but I
didn't realize you also use the same interface to create builtins. Did
you still need modify loop-unroll.c or other gcc files to detect
preceding "customop_unroll_pragma" instruction?
Cheers,
Bingfeng
-Original Message-
From: Alex Turjan [mailto:[EMAIL PROTECTED]
Sent: 30 May 2008 08:55
To: Bingfeng Mei; gcc@gcc.gnu.org
Subject: RE: Implement #pragma unroll?
Bingfeng,
to define the pragma you use something like this:
#define REGISTER_TARGET_PRAGMAS()
{
c_register_pragma (0, "unroll_factor",
support_unroll_pragma);
}
such that when you compile a loop like this you get it
unrolled 20 times:
#pragma unroll_factor=20
for(i = 0; i < 40; i++){
m[i]=3;
}
then you have to implement the support_unroll_pragma
function
which in my case I used it to extract the unrolling
factor (in this case 20)
and to insert in the parse tree an intrinsic. Here is
my code:
void
support_unroll_pragma (cpp_reader * pfile
ATTRIBUTE_UNUSED)
{
tree x;
enum cpp_ttype token;
int unroll_factor = 0;
token = pragma_lex (&x);
gcc_assert (token == CPP_EQ);
token = pragma_lex (&x);
gcc_assert (token == CPP_NUMBER);
unroll_factor = TREE_INT_CST_LOW (x);
tree type =
build_function_type_list (void_type_node,
integer_type_node, NULL_TREE);
tree t = build_fn_decl ("__unroll_pragma", type);
enum built_in_function code = DECL_FUNCTION_CODE
(t);
DECL_BUILT_IN_CLASS (t) = BUILT_IN_MD;
TREE_PUBLIC (t) = 1;
DECL_EXTERNAL (t) = 1;
DECL_FUNCTION_CODE (t) =
builtin_line_no("__unroll_pragma");
tree operand = build_int_cst (NULL_TREE,
unroll_factor);
t = build_call_expr (t, 1, operand);
add_stmt (t);
}
trimedia_builtin_line_no generates a call described by
the following pattern:
(define_insn "customop_unroll_pragma"
[(unspec_volatile:SI
[
(match_operand:SI 0
"immediate_operand" "i")
] UNSPEC_unroll_pragma)
]
""
""
)
which in loop-unroll (where you have RTL instructions)
is caught with the
with something like this:
(INSN_P(insn) && recog_memoized(insn) ==
CODE_FOR_customop_unroll_pragma
more or less this is it.
Alex
--- Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Alex, Thanks for your suggestion. What target hook
> do you use for the
> backend function?
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Alex Turjan
> Sent: 29 May 2008 14:45
> To: gcc@gcc.gnu.org
> Subject: RE: Implement #pragma unroll?
>
> Dear Bingfeng,
> Some time ago I had to deal with a similar issue as
> you. Basically I did as follows: I built a backend
> function which catches the unroll pragma and
> replaces
> it with a target assembly intrinsic (which of course
> has to be described in an .md file). After that in
> the
> RTL unroll phase, I analyze loop by loop and connect
> them to the corresponding unrolling intrinsic (which
> as a field contains the unrolling factor, you may
> add
> here extra information which allows you to recognize
> the loop) from where I decide the unrolling factor.
> After that in the RTL unroll phase I remove all the
> unroll intrinsics.
> hope this will help,
> Alex
>
>
>
>
>
>
>
Question about building hash values from pointers
Hi,
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long scalar
is wide enough for a pointer. This is at least for w64 target not true. So
I want to know, if it would be good to introduce an gcc specific type for
those kind of casts, or to use ssize_t/size_t.?
Regards,
Kai
Btw: I noticed that while trying to debug the native w64 compiler, which
always crashes in c-common.c:6748 in field_decl_cmp (a cross-compiler
version does not crash?!).
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Question about building hash values from pointers
Kai Tietz wrote: > as I noticed, most hash value calculations are trying to use pointer > values for building the value and assume that a long/unsigned long scalar > is wide enough for a pointer. This is at least for w64 target not true. So > I want to know, if it would be good to introduce an gcc specific type for > those kind of casts, or to use ssize_t/size_t.? Why would it matter? Are there any circumstances is which not using the upper part of an address will reduce performance or break something? Andrew.
Re: Question about building hash values from pointers
Andrew,
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 11:45:50:
> Kai Tietz wrote:
>
> > as I noticed, most hash value calculations are trying to use pointer
> > values for building the value and assume that a long/unsigned long
scalar
> > is wide enough for a pointer. This is at least for w64 target not
true. So
> > I want to know, if it would be good to introduce an gcc specific type
for
> > those kind of casts, or to use ssize_t/size_t.?
>
> Why would it matter? Are there any circumstances is which not using the
> upper part of an address will reduce performance or break something?
>
First of all it matters about warnings. The native build of w64 gcc is
full of 'cast from pointer to integer of different size. The second, IMHO
the more important reason, is that a general type to express a host
pointer scalar size would prevent such bugs as in PR/36386.
Cheers,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Question about building hash values from pointers
On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> as I noticed, most hash value calculations are trying to use pointer
> values for building the value and assume that a long/unsigned long scalar
> is wide enough for a pointer. This is at least for w64 target not true. So
> I want to know, if it would be good to introduce an gcc specific type for
> those kind of casts, or to use ssize_t/size_t.?
it's uintptr_t which should be used, if only as an intermediate cast -
(unsigned long)(uintptr_t)ptr.
The effect of not including the upper half of the pointer shouldn't reduce
the quality of the hash too much.
Richard.
> Regards,
> Kai
>
> Btw: I noticed that while trying to debug the native w64 compiler, which
> always crashes in c-common.c:6748 in field_decl_cmp (a cross-compiler
> version does not crash?!).
>
> | (\_/) This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
>
Re: Question about building hash values from pointers
Kai Tietz wrote: > Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 11:45:50: > >> Kai Tietz wrote: >> >>> as I noticed, most hash value calculations are trying to use pointer >>> values for building the value and assume that a long/unsigned long > scalar >>> is wide enough for a pointer. This is at least for w64 target not > true. So >>> I want to know, if it would be good to introduce an gcc specific type > for >>> those kind of casts, or to use ssize_t/size_t.? >> Why would it matter? Are there any circumstances is which not using the >> upper part of an address will reduce performance or break something? > > First of all it matters about warnings. The native build of w64 gcc is > full of 'cast from pointer to integer of different size. The second, IMHO > the more important reason, is that a general type to express a host > pointer scalar size would prevent such bugs as in PR/36386. If what Andrew Pinski says is true, this is not a bug at all. Not that I'm against fixing warnings, of course; using long where size_t is meant is probably a hangover from the days when gcc had to compile on non-ISO C. You can't use ssize_t, though, as it's nonstandard. Andrew.
Re: Question about building hash values from pointers
Richard Guenther wrote: > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote: >> Hi, >> >> as I noticed, most hash value calculations are trying to use pointer >> values for building the value and assume that a long/unsigned long scalar >> is wide enough for a pointer. This is at least for w64 target not true. So >> I want to know, if it would be good to introduce an gcc specific type for >> those kind of casts, or to use ssize_t/size_t.? > > it's uintptr_t which should be used, if only as an intermediate cast - > (unsigned long)(uintptr_t)ptr. That's not possible because, IIRC, gcc must compile on C90 systems. Andrew.
Re: Question about building hash values from pointers
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 12:07:49:
> Richard Guenther wrote:
> > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]>
wrote:
> >> Hi,
> >>
> >> as I noticed, most hash value calculations are trying to use pointer
> >> values for building the value and assume that a long/unsigned long
scalar
> >> is wide enough for a pointer. This is at least for w64 target not
true. So
> >> I want to know, if it would be good to introduce an gcc specific type
for
> >> those kind of casts, or to use ssize_t/size_t.?
> >
> > it's uintptr_t which should be used, if only as an intermediate cast -
> > (unsigned long)(uintptr_t)ptr.
>
> That's not possible because, IIRC, gcc must compile on C90 systems.
Right, so the only type remaining is size_t. IIRC there is problem for
this type on some targets, too. AFAIC there are 24-bit pointers ...
This is the reason, why I was querying to introduce a new general type for
such stuff in gcc.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Question about building hash values from pointers
it's uintptr_t which should be used, if only as an intermediate cast - (unsigned long)(uintptr_t)ptr. That's not possible because, IIRC, gcc must compile on C90 systems. Right, so the only type remaining is size_t. IIRC there is problem for this type on some targets, too. AFAIC there are 24-bit pointers ... This is the reason, why I was querying to introduce a new general type for such stuff in gcc. size_t is ok I think, but just in case, there is an autoconf macro (used in libgfortran and libdecnumber) that provides int*_t. Paolo
Re: Question about building hash values from pointers
Andrew Haley <[EMAIL PROTECTED]> writes: > Richard Guenther wrote: >> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> as I noticed, most hash value calculations are trying to use pointer >>> values for building the value and assume that a long/unsigned long scalar >>> is wide enough for a pointer. This is at least for w64 target not true. So >>> I want to know, if it would be good to introduce an gcc specific type for >>> those kind of casts, or to use ssize_t/size_t.? >> >> it's uintptr_t which should be used, if only as an intermediate cast - >> (unsigned long)(uintptr_t)ptr. > > That's not possible because, IIRC, gcc must compile on C90 systems. We can just test for it with autoconf and typedef it if we don't have it. We can figure out what to typedef it to by comparing the sizeof void* to the sizeof the integer types--we already gather these sizes in the configure script anyhow, and use them in hwint.h. Ian
Re: GCC 4.3.1 second Release Candidate available from gcc.gnu.org
On Thu, May 29, 2008 at 01:57:51PM +0200, Richard Guenther wrote: > > A second release candidate for GCC 4.3.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.1-RC-20080529 > > and shortly its mirrors. It has been generated from SVN revision 136151. Nice to see that it still builds and runs on RHEL 3, which I hadn't tried in a while (with a newer binutils and MPFR): http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02605.html Lots of UNRESOLVED, some of which seems to be caused by using a really old glibc, but if anyone's curious about the details of any of those failures please let me know.
gcc-4.4-20080530 is now available
Snapshot gcc-4.4-20080530 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080530/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 136224 You'll find: gcc-4.4-20080530.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080530.tar.bz2 C front end and core compiler gcc-ada-4.4-20080530.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080530.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080530.tar.bz2 C++ front end and runtime gcc-java-4.4-20080530.tar.bz2 Java front end and runtime gcc-objc-4.4-20080530.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080530.tar.bz2The GCC testsuite Diffs from 4.4-20080523 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
