Abt RTL expression

[Revital1 Eres]

(insn 8 6 9 1 (parallel [
(set (reg/f:SI 32)
(symbol_ref:SI ("t") ))
(clobber (reg:CC 21 cc))
]) -1 (nil)
(nil))

Here is an answer to your first question:

8 6 9 are the serial numbers of the current, previous and next instructions
in the instructions link list;
1 is the serial number of the instruction basic block.
You can read more about the RTL representation of insn in
http://gcc.gnu.org/onlinedocs/gccint/Insns.html.

Also, the following are taken from http://gcc.gnu.org/onlinedocs/gccint/:

clobber indicates something is clobbered in a way that we don't want to
explain.
For example, subroutine calls will clobber some physical registers.

reg/f - In reg expressions, 1 means that the register holds a pointer.

Revital

Compiling with profiling flags

[Revital1 Eres]

Hello,

Is there an option to change the name of the .gcno file that is generated
by using profiling
flags like -fprofile-generate and later used by -fprofile-use?
I read that "For each source file compiled with `-fprofile-arcs', an
accompanying
 `.gcda' file will be placed in the object file directory. " - Can I change
it such that
the .gcda will be named as I wish?

Thanks

Re: Abt RTL expression

[Revital1 Eres]

>  a) To which register is the value of n copied? if a5 is the register
> what is 13 and [28]
All of those numbers refer to the same register -
13 is the number of the register; a5 is the name of the register
(if it is an hard register);
[28] is the number of the old pseudo register.
(please look at ORIGINAL_REGNO in rtl.h for more info)

>  b) what is  [flags 0x2] 
[flags 0x2] are symbol_ref flags and var_decl is the tree decl associated
with this symbol.
(see SYMBOL_REF_FLAGS in rtl.h)

>
> 2.(insn 12 11 13 0 gcc/testsuite/gcc.c-torture/execute/20020611-1.c:13
> (set (reg:SI 0 d0 [orig:29 n ] [29])
> (mem/c/i:SI (reg/f:SI 13 a5 [28]) [2 n+0 S4 A32])) 15
> {movsi_load} (insn_list:REG_DEP_TRUE 11 (nil))
> (expr_list:REG_DEAD (reg/f:SI 13 a5 [28])
> (expr_list:REG_EQUAL (mem/c/i:SI (symbol_ref:SI ("n") [flags
> 0x2] ) [2 n+0 S4 A32])
> (nil
>
> a) what does this mean  [orig:29 n ] [29] in the above expression?
As above; [orig:29 n ] [29] are the numbers of the old
pseudo register.

> b) what does this mean [2 n+0 S4 A32] in the above expression?

[2 n+0 S4 A32] contains information on the memory expression -
2 is the alias set (MEM_ALIAS_SET);n is the base memory expression and 0 is
it's offset
;S4 is the size in bytes of the memory expression (MEM_SIZE) and A32 is the
alignment in bits (MEM_ALIGN).

Hope it helps,
Revital

Re: Register Usage - RTL Expression

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 30/10/2006 15:25:09:

> Hi all,
>
> I am working with GCC Cross compiler 4.1.1.  I just some information
> regarding the following:
>
> 1. How does the life1 pass gets the register usage information from
> the gcse pass?
AFAICT life1 pass calculates the live registers from scratch.
It stores the information in each basic block.

> 2. From which other passes and how, the information about registers
> used can be determined by looking at the RTL dump of the corresponding
> pass?
You can look at 'registers live:' information
in the beginning of each basic-block in the dumps (if it is available).

Revital

Re: Abt an RTL expression

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 31/10/2006 12:01:20:

> Hello all,
>
> Can anyone tell me what the below expression means ?
>
>
> (insn 38 37 40 4 (parallel [
> (asm_operands/v ("") ("") 0 [  //line
2
> (reg:SI 32 [ s5.1 ])
>   //line 3
> ]
>  [
> (asm_input:SI ("r"))
>  //line 6
> ] ("test55.c") 42)
>   //line 7
> (clobber (mem:BLK (scratch) [0 A8]))
>   //line 8
> ]) -1 (nil)
> (nil))
>
> in line 2,  what is the 0 for?
>
> what does line 3 mean?what is it purpose ?
>
> In line 7 test55.c is the file name . why is it needed and what is 42?

ASM_OPERANDS operands contains
line number and source file.  Please see
http://gcc.gnu.org/onlinedocs/gccint/Assembler.html#Assembler
for the structure of assembler instructions.

> In line 8 what does [0 A8] mean?

[0 A8] contains information on the memory expression.
Please see the last sentence in
http://gcc.gnu.org/ml/gcc/2006-10/msg00462.html.

Hope it helps,
Revital

Re: Induction variable optimization

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 06/11/2006 03:34:27:

> Respected Sir
>
> I am a M.E.Computer science student and doing project on induction
variable
> optimization.
>
> Therefore i am reading the file tree-ssa-loop-ivopts.c of gcc-4.0.2 to
know
> about what have implemented in that.
>
> Is there any other way to know about what have implemented yet and in
> gcc-4.0.2. Can i know the algorithm.? Please help me to figure it out.
>
> Thanking you.
>
>
> Rama Bharti Varshney
> id: 2005h103421
> Bits-Pilani(Rajasthan)
> India.
>
>

Mabye "Induction variable analysis with delayed abstractions" paper by
Sebastian Pop, Georges-André Silber and Albert Cohen can help.

-funsafe-math-optimizations and -fno-rounding-math

[Revital1 Eres]

Hello,

-fno-rounding-math enables the transformation of (-(X - Y)) -> (Y - X)
in simplify-rtx.c  which seems to be the same transformation
that enabled by -funsafe-math-optimizations in fold-const.c.

If I understand currently -frounding-math means that the rounding mode is
important.
In that case should there be correlation between
-funsafe-math-optimizations
and -fno-rounding-math (which currently does not exist)?

Thanks,
Revital

Re: writing a new pass: association with an option string

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 04/12/2006 10:48:25:

> Dear all,
> I wrote a new pass for gcc. Actually the pass is always executed, but
> I'd like to execute it only if I specify an option from shell (ex. gcc
> --mypass pippo.c). How can I do?

Maybe adding a gate to your pass which is controlled by a new flag;
for example see pass_vectorize in passes.c
and gate_tree_vectorize in tree-ssa-loop.c.

Revital

Re: writing a new pass: association with an option string

[Revital1 Eres]

> Create a new flag in common.opt and read its value in the gate function
> of your pass.  I *believe* this is documented somewher in the internals
> manual, but I'm not sure.

See also -
http://gcc.gnu.org/wiki/WritingANewPass

Re: Interface for manipulating the abstract syntax tree

[Revital1 Eres]

> I try to change the front-end tree structure of a c/c++ program as a
> side effect of execution of a pragma. The operations that are involved
> is to walk through in a tree (i.e "C" block), insertion of a tree
> (i.e. statement, block, declaration) in the abstract syntax tree and
> deletion of a tree (i.e. statement, block, declaration).

You can access the function's tree through it's call-graph node. (the
call-graph
node has a pointer to the function's tree declaration), than use
block_stmt_iterator (bsi) to iterate through the function's basic blocks;
each statement in the basic block can be recursively traversed via
walk_tree () function.  (see cgraph_create_edges () in cgraphunit.c).
build1 () function (tree.h) can be used to construct a new tree node.

Hope it helps,
Revital

Re: Interface for manipulating the abstract syntax tree

[Revital1 Eres]

> /* below I pass a the tree of the current_function_decl a global
> variable in tree.h */
> this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);
> FOR_EACH_BB_FN(bb, this_cfun) /* Crashes here, Also tried with
> FOR_EACH_BB */
> for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
> {
>bsi_stmt(bsi);
> }
> bsi = bsi_for_stmt(current_function_decl); /* Crashes right here */
> }

bsi_for_stmt(current_function_decl); does not seems correct to me
as it should return the function's declaration's basic block
iterator; which does not belongs to bb.

I think you are also missing some statement to get the current
tree node in the loop:

tree stmt = bsi_stmt (bsi);
and later recursively manipulate it with walk_tree ().

Please look how it is done in cgraph_create_edges().

Revital

Re: Interface for manipulating the abstract syntax tree

[Revital1 Eres]

>
> And the code crashes at the macro FOR_EACH_BB_FN.. This is exatly as
> it is implemented in cgraph_create_edges() function.. but I think that
> the problem is because I call it at wrong time (too early, or too late
> - before or after parsing).. Could it be?

Yes.  You can start by calling it in the same place cgraph_create_edges ()
is been called. (cgraph_analyze_function ())

> When cgraph_create_edges() function is called it is passed a
> function's declaration tree. In my case I also pass a function
> declaration tree:
>
> this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);

Check if current_function_decl is actually set when you access it.
You can learn more by looking at the function that calls
cgraph_create_edges()
which sets current_function_decl.

Revital

Re: SSE (Pentium 3) - Is this correct?

[Revital1 Eres]

> The C code:
>
> float *vector_add4f(float va[4], const float vb[4])
> {
>   va[0] += vb[0];
>   va[1] += vb[1];
>   va[2] += vb[2];
>   va[3] += vb[3];
>   return va;
> }

> Now, uh, isn't that four additions? Do I need to do something
gcc-specific
> to get it to use the 'add-packed-single' instruction to turn those four
> additions into one?

-ftree-vectorize flag is missing.
(see http://gcc.gnu.org/projects/tree-ssa/vectorization.html for more info
about
the flags you should use)
Also, currently the vectorizer is applied only on loops. (please see the
Auto-vectorization
page for examples)

Revital

Re: Creating a variable declaration of custom type.

[Revital1 Eres]

> tree type_id, type_node, var_decl;
>
> type_id = get_identifier("MyType");
> type_node = make_node(POINTER_TYPE);
> TYPE_NAME(type_node) = type_id;
> var_decl = build(VAR_DECL, get_identifier("t"), type_node);
>
> But, when I compile my source with the modified GCC (as above) I get
> an error: "t" has an incomplete type. I know that I miss something but
> I cannot figure out what is it.

I think that the type of type_node is missing.  Try to add
TREE_TYPE (type_node); For example TREE_TYPE (type_node) =
integer_type_node. (if MyType is int).

Revital

>
> --
> Ferad Zyulkyarov
> Barcelona Supercomputing Center

Re: Creating a variable declaration of custom type.

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 16/01/2007 17:45:59:

> I succeeded to do it as follows:
>
> tree type_decl = lookup_name(get_identifier("MyType"));
> tree type_ptr = build_pointer_type(TREE_TYPE(type_decl));
> tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);
> pushdecl(var_decl);
>
> It may not be a perfect solution but for now it works.
>
> On 1/16/07, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > > Best way to figure this out is to write a simple 5 line testcase that
> > > defines a structure type and also defines a pointer to that type, and
> > > then step through gcc to see what it does.  Try putting breakpoints
in
> > > finish_struct and build_pointer_type.
> >
> > I tried with the advised test case but again I could not find how to
> > reference to the already declared type "MyType".
> >
> > As it sould be logically, there should be a way to get a reference to
> > the declared type i.e.
> > tree type_decl = lookup_name("MyType");
> > tree type_ptr = build_pointer_type(type_decl->type_node);
> > tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);
> >
> > I tried similar codes like the above, but I don't know how to retrieve
> > the "type" from the type declaration. Any help, ideas are highly
> > appreciated.
> >

BTW - I think you can retrieve a reference to an existing type by
traversing the
type_hash hash in tree.c.

Revital


> > Ferad Zyulkyarov
> >
>
>
> --
> Ferad Zyulkyarov
> Barcelona Supercomputing Center

Re: About implementing new intrinsic

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 14/02/2007 19:34:48:

> Hi,
>
> I try to introduce a new intrinsic in gcc's back-end, for the alpha
> machines. In doing that, I referenced to the implementaions of altivec
> intrinsics for the PowerPC. In the mean time I noticed that the
> gcc-4.0 and gcc-4.1 implements these in different way which confused
> me. The difference is that in 4.0 for each intrinsic is defined a in
> inline template function and/or macro. gcc-4.1 and later miss these
> definition.
>

Hi,

I am not sure if this message is still relevant.  Anyhow, I think
following another built-in under zero_arg_builtins ("__builtin_alpha_rpcc"
in alpha.c for example) could help in finding the missing part in this
implementation.

Revital

Re: About implementing new intrinsic

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 18/02/2007 17:01:31:

> Hi,
>
> >
> > I am not sure if this message is still relevant.  Anyhow, I think
> > following another built-in under zero_arg_builtins
("__builtin_alpha_rpcc"
> > in alpha.c for example) could help in finding the missing part in this
> > implementation.
> >
>
> the message is still relevant. I tried to use as example the currently
> existing intrinsics. But there is something that I miss. For example,
> CODE_FOR_* constants/variables (pointer to function) are supposed to
> be defined in some source file but I couldn't find where. At compile
> time I got an error that it is not defined. I suppose that when GCC is
> being compiled some automatic code generation happens (from machine
> descriptors) that defines these CODE_FOR_* variables.

Try to write

 (define_insn "builtin_myintrinsic"
 [(unspec_volatile [(const_int 0)] 101)]
 ""
 "xor $31, $0, $31")

instead of

(define_insn "myintrinsic"
 [(unspec_volatile [(const_int 0)] 101)]
 ""
 "xor $31, $0, $31")

in alpha.md, I think this will solve the CODE_FOR_* problem.

Revital

reassociation pass and built-in functions

[Revital1 Eres]

Hello,

We saw that the reassociation pass does not operate on built-in functions,
for example:

vp3 = vec_madd (vp1, vp2, vp3);

In the RTL level the function is expanded to regular insn:

(insn 87 91 88 9 (set (reg/v:V4SF 217 [ vp3 ])
(plus:V4SF (mult:V4SF (reg/v:V4SF 219 [ vp1 ])
(reg/v:V4SF 218 [ vp2 ]))
(reg/v:V4SF 217 [ vp3 ]))) -1 (nil)
(nil))


The reassociation could open opportunity for the variable expansion
optimization to be applied when vec_madd is in a loop.
(this is what the reassociation pass do for similar accumulation
instruction that is not in built-in function)
Currently MVE fails as it expects the pattern:

x = x + something

while it finds:

x = something + x

I could fix this in the MVE code, but I was wondering about the
relations of reassociation pass and built-in functions in general.

Thanks,
Revital

Re: About implementing new intrinsic

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 18/02/2007 17:01:31:

> Hi,
>
> >
> > I am not sure if this message is still relevant.  Anyhow, I think
> > following another built-in under zero_arg_builtins
("__builtin_alpha_rpcc"
> > in alpha.c for example) could help in finding the missing part in this
> > implementation.
> >
>
> the message is still relevant. I tried to use as example the currently
> existing intrinsics. But there is something that I miss. For example,
> CODE_FOR_* constants/variables (pointer to function) are supposed to
> be defined in some source file but I couldn't find where. At compile
> time I got an error that it is not defined. I suppose that when GCC is
> being compiled some automatic code generation happens (from machine
> descriptors) that defines these CODE_FOR_* variables.
>

BTW - In the 2nd HiPEAC GCC Tutorial you can find some useful information
which can help when adding a new built-in function.  (in particular -
'Extending GCC with new operations: RTL, SIMD and treecodes' and
'The compilation flow of the auto-vectorizer')

Revital

Generate -zero RTX expression

[Revital1 Eres]

Hello,

I appreciate it if someone could tell me how I can create a -0 RTX
expression (like CONST0_RTX)?

Thanks,
Revital

REG_ALLOC_ORDER and Altivec registers

[Revital1 Eres]

Hello,

I wonder why this order (non-consecutive, decreasing) of Altivec registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.

(taken from rs6000.h)

   /* AltiVec registers.  */\
   77, 78,  \
   90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80,  \
   79,  \
   96, 95, 94, 93, 92, 91,  \
   108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, \
   109, 110,\
   111, 112, 113\

Thanks,
Revital

Re: Manipulating the tree Structure

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 12/03/2007 16:56:53:

> Hi all,
> i have a very little question for you. I have a basic block and by a
> statement iterator i can obtain a tree structure in the following
> manner:
>  tree stmt = bsi_stmt (si);
> I want to use this tree structure to manipulate the statement, for
> example i 'd like to know if statement is an assignement or another
> instruction type. And if the statement is an assignement i'd like to
> know wich is the name of the variable.
> I have serchead too much but i have not found any information.
> Thanks to all,

You can use the TREE_CODE of stmt to know that instruction type.
Almost all the tree-* files manipulate the stmt tree so you can grep
in those files to find more examples.

Revital


> Andrea Callia D'Iddio

Error in checking compat.exp

[Revital1 Eres]

Hello,

I get the following error while running
make check-gcc RUNTESTFLAGS="compat.exp"
with mainline gcc version 4.3.0 20070312
on PPC.

Revital

 === g++ tests ===

Schedule of variations:
unix

Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file
for target.
Using
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp
 ...
ERROR: tcl error sourcing
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
ERROR: couldn't open
"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C":
 no such file or directory
while executing
"open $file r"
(procedure "grep" line 19)
invoked from within
"grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
(procedure "dg-get-options" line 4)
invoked from within
"dg-get-options $src"
(procedure "compat-get-options" line 12)
invoked from within
"compat-get-options $src2"
(procedure "compat-execute" line 34)
invoked from within
"compat-execute $src $sid $use_alt"
("foreach" body line 7)
invoked from within
"foreach src [lsort [find $srcdir/$subdir *_main.C]] {
# If we're only testing specific files and this isn't one of them, skip
it.
if ![runtest..."
(file
"/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp"
 line 119)
invoked from within
"source
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""

Re: Error in checking compat.exp

[Revital1 Eres]

> > I'll find a way to fix that.
>
> Revital, please try this.  I've tested it but know better than to check
> things in at the end of the day; I'll post it tomorrow.

It fixes the problem.

Thanks,
Revital

Problem with building libgfortran on PPC

[Revital1 Eres]

Hello,

I get the following error on PPC while bootstrapping mainline.

Re-runing make I get:

collect2: ld terminated with signal 11 [Segmentation fault]
make[8]: *** [libstdc++.la] Error 1

Thanks,
Revital


ranlib .libs/libgfortran.a
creating libgfortran.la
(cd .libs && rm -f libgfortran.la && ln -s ../libgfortran.la
libgfortran.la)
make[6]: Nothing to be done for `all-am'.
make[6]: Leaving directory
`/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/nof/libgfortran'
make[5]: Leaving directory
`/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/nof/libgfortran'
make[4]: Leaving directory
`/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran'
make[2]: Leaving directory
`/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran'
make[1]: Leaving directory `/home/eres/check_ifcvt_fix/build'
make: *** [bootstrap] Error 2

Re: Problem with building libgfortran on PPC

[Revital1 Eres]

>
> I've been using binutils 2.17 on various distributions of powerpc64-linux
> and have had no problem with it.

I used binutils 2.15. I guess this is the problem.

Thanks,
Revital

>
> Janis

Bootstrap comparison failure with -O2 -funroll-loops -funsafe-math-optimizations

[Revital1 Eres]

Hello,

I get the following error while bootstraping mainline with -O2
-funroll-loops -funsafe-math-optimizations options on PPC.

Thanks,
Revital

make[3]: Leaving directory `/home/revitale/mainline_zero_mve/build'
Comparing stages 2 and 3
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./ipa-inline.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/revitale/mainline_zero_mve/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/revitale/mainline_zero_mve/build'
make: *** [bootstrap] Error 2

Re: 4.3 bootstrap broken on i386-linux

[Revital1 Eres]

Hello,

I get similar error with recent mainline on PPC.

../../../../gcc/libgcc/../libdecnumber/decLibrary.c:71: error: expected ';'
before 'd128'
../../../../gcc/libgcc/../libdecnumber/decLibrary.c:73: error: 'd128'
undeclared (first use in this function)
../../../../gcc/libgcc/../libdecnumber/decLibrary.c:73: error: too many
arguments to function '_128'
../../../../gcc/libgcc/../libdecnumber/decLibrary.c:74: warning: implicit
declaration of function 'decimal128ToNumber'
../../../../gcc/libgcc/../libdecnumber/decLibrary.c:74: error: 'dn'
undeclared (first use in this function)
make[4]: *** [decLibrary.o] Error 1
make[4]: Leaving directory
`/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/64/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2

Revital

Re: Question about SMS scheduling windows

[Revital1 Eres]

Hello Richard,

> I ask because in the final range:
>
>   start = early_start;
>   end = MIN (end, early_start + ii);
>   /* Schedule the node close to it's predecessors.  */
>   step = 1;
>
> END is an exclusive bound.  It seems like we might be double-counting
here,
> and effectively limiting the schedule to SCHED_TIME (v_node) + ii - 2.

Yes, I think it indeed should be fixed. Thanks for reporting on this.

Revital

Vectorizing invariant data-ref

[Revital1 Eres]

Hello,

The following snippet is from a f90 program which contains
a loop that does not get vectorized.

SUBROUTINE foo1(nx,ny,nz,arr2)
USE globalvar_mod, ONLY : dyinv, xstart, xstop

k=1
do j=1,ny
  do i=1,nx

arr1(i,j,k) = arr2(i,j,k  ) *dyinv

  end do
end do
END SUBROUTINE foo1

The vectorizer failure message is:

base_address: &dyinv
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: dyinv
FAILED as dr address is invariant

test41.f90:24: note: get vectype with 2 units of type real(kind=8)
test41.f90:24: note: vectype: vector real(kind=8)
test41.f90:24: note: not vectorized: unhandled data-ref
test41.f90:24: note: bad data references.
test41.f90:7: note: vectorized 0 loops in function.

I am not familiar with f90 at all; seemingly dyinv is a regular
variable but according to the message in the dump file
it's a reference.

One option to vectorize this loop is to extend the vectorizer's versioning
for aliasing capability to version the loop also in this case.
Other suggestions will be appreciated.

Thanks,
Revital


(See attached file: test41.f90.txt)
MODULE foo_mod
USE parameter_mod, ONLY : rfp

IMPLICIT NONE

PUBLIC foo1

PRIVATE
real(kind=rfp), dimension(:,:,:), allocatable :: arr1

CONTAINS
SUBROUTINE foo1(nx,ny,nz,arr2)
USE globalvar_mod, ONLY : dyinv, xstart, xstop

integer, intent(in) :: nx, ny, nz
real(kind=rfp), intent(inout),&
 dimension(xstart:xstop+1,xstart:xstop+1,xstart:xstop+1) :: arr2

integer :: i, j, k

k=1
do j=1,ny
  do i=1,nx

arr1(i,j,k) = arr2(i,j,k  ) *dyinv

  end do
end do


END SUBROUTINE foo1

END MODULE foo_mod

Re: Vectorizing invariant data-ref

[Revital1 Eres]

Hello,

> The testcase is from 459.GemsFDTD, right?  dyinv is a regular
> global variable.  The issue is the global arrays arr1 and arr2 end
> up pointing to anything even though the Fortran aliasing rules say
> the do not.

Yes, the testcase is from 459.GemsFDTD.

> We are working on this issue.

Great, thanks,
Revital

>
> Thanks,
> Richard.
>
> > Thanks,
> > Revital
> >
> >
> > (See attached file: test41.f90.txt)

error in hash.cc

[Revital1 Eres]

Hello,

I get the following error while compiling gcc -r150679 on ppc

Thanks,
Revital

  

  
  unknown-linux-gnu/libstdc++-v3/include 
-I/home/eres/mainline_45/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates  
  -Wall -Wextra -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g   
  -O2 -D_GNU_SOURCE -mlong-double-64 -c 
../../../../gcc/libstdc++-v3/src/compatibility-ldbl.cc -fPIC -DPIC
  -o .libs/compatibility-ldbl.o 
  
  In file included from 
../../../../gcc/libstdc++-v3/src/compatibility-ldbl.cc:71:0:
  
  ../../../../gcc/libstdc++-v3/src/hash.cc:29:9: error: expected 
initializer before ג<ג token 
  ../../../../gcc/libstdc++-v3/src/compatibility-ldbl.cc:76:17: 
error: גvoid _ZNKSt4hashIeEclEe()ג aliased to 
  undefined symbol ג_ZNKSt3tr14hashIeEclEeג 
  
  make[4]: *** [compatibility-ldbl.lo] Error 1  
  
  make[4]: Leaving directory 
`/home/eres/mainline_45/new_build/powerpc64-unknown-linux-gnu/libstdc++-v3/src' 
 
  make[3]: *** [all-recursive] Error 1  
  
  make[3]: Leaving directory 
`/home/eres/mainline_45/new_build/powerpc64-unknown-linux-gnu/libstdc++-v3' 
 
  make[2]: *** [all] Error 2
  
  make[2]: Leaving directory 
`/home/eres/mainline_45/new_build/powerpc64-unknown-linux-gnu/libstdc++-v3' 
 
  make[1]: *** [all-target-libstdc++-v3] Error 2
  
  make[1]: Leaving directory `/home/eres/mainline_45/new_build' 
  
  make: *** [all] Error 2   
  

  

Error in fortran/module.c

[Revital1 Eres]

Hello,

I get the following error while bootstrap on x86_64:

Thanks,
Revital


/home/revitale/test_mainline_45/build/./prev-gcc/xgcc
-B/home/revitale/test_mainline_45/build/./prev-gcc/
-B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/bin/
-B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/bin/
-B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/lib/
-isystem /home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/include

-isystem 
/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/sys-include
-c  -O3 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Werror -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-I. -Ifortran -I../../gcc/gcc -I../../gcc/gcc/fortran
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/usr/local//include -I/opt/cfarm/mpfr-2.3.1//include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber../../gcc/gcc/fortran/module.c -o fortran/module.o
cc1: warnings being treated as errors
../../gcc/gcc/fortran/module.c: In function גmio_f2k_derivedג:
../../gcc/gcc/fortran/module.c:3465:19: error: גopג may be used
uninitialized in this function.
make[3]: *** [fortran/module.o] Error 1
make[3]: Leaving directory `/home/revitale/test_mainline_45/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/revitale/test_mainline_45/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/revitale/test_mainline_45/build'
make: *** [bootstrap] Error 2

Re: GCC's data dependence analyse may inaccuracy

[Revital1 Eres]

Hello,

> I unroll the following code one times in a gimpile pass.

Can you please post the flags you used and the full test?
I can try to reproduce this.

Thanks,
Revital

A question about loop-unroll

[Revital1 Eres]

Hello,

Is there a way to pass to the unroller the maximum number of iterations
of the loop such that it can decide to avoid unrolling if
the maximum number  is small.

To be more specific, I am referring to the following case:
After the vectorizer decides to peel for alignment
it creates three loops:
[1] scalar loop - the prologue to align
memory access.
[2] the vecorized loop
[3] scalar loop - the remaining scalar computations.

If the unroller does not know the number of  iterations at compile time
it unrolls loops with run-time checks in the following way
(taken from loop-unroll.c):

   for (i = 0; i < n; i++)
 body;

   ==>

   i = 0;
   mod = n % 4;

   switch (mod)
 {
   case 3:
 body; i++;
   case 2:
 body; i++;
   case 1:
 body; i++;
   case 0: ;
 }

   while (i < n)
 {
   body; i++;
   body; i++;
   body; i++;
   body; i++;
 }


The vectorizer knowns at compile time the maximum number of iterations
that will be needed for the prologue and the epilogue. In some cases
seems there is no need to unroll and create redundant loops.

Thanks,
Revital

A question regarding recognition of nop

[Revital1 Eres]

Hello,

Is there a general way to recognize a nop insn in RTL (using attributes?),
or should I add a target hook for that?

For example, I would like to recognize the following spu insn as a nop:?),

(insn 555 210 203 11 (unspec_volatile [
(const_int 0 [0x0])
] 14) 393 {lnop} (nil))

Thanks,
Revital

A question about DCE

[Revital1 Eres]

Hello,

I want to emit the following SPU insn:
emit_insn (gen_iorti3 (r77, tmp, GEN_INT(0)));

r77 is defined as 'fixed register' which is a register that the register
allocator can not use.  (triggers by SPU option -mfixed-range)
r77 is used to pass information to some other routine at run-time (the
next instruction is branch to this routine; the routine does not exist
at the compile time of the function which contains this instruction).

The problem is that r77 is not used in it's function after this instruction
and thus DCE deletes it.

My question is as follows:
I understood I can not make DCE ignore an insn.  However,
can I teach DCE to ignore instructions which sets fixed register?
(or there is another way to make DCE ignore that insn)

Thanks,
Revital

Re: A question about DCE

[Revital1 Eres]

Hello,

> > The problem is that r77 is not used in it's function after this
instruction
> > and thus DCE deletes it.
>
> Don't focus on DCE.  That's not the problem; the fact that there's no
> visible dependence is the problem.  Can you make the next instruction
> have a use for r77 explicitly (CALL_INSN_FUNCTION_USAGE)?

Thanks for all the replies.

I received a similar suggestion from David Edelsohn which told me to use -
emit_insn (gen_rtx_USE (VOIDmode, r77));
similar to use_reg() function in expr.c;

That seems to solve the problem.

Thanks again,
Revital

Re: Which target has working modulo scheduling?

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 17/10/2008 16:36:32:

> Hello,
> I tried to enable modulo scheduling for our target VLIW. It fails even
for the
> simplest loop. I would like to have a look at how GCC produces schedule
for
> other targets. I know that modulo scheduling relies on doloop_end pattern
to
> identify a pipelineable loop. There are only a handful of targets
supporting
> doloop_end. Which among them are known to work well with modulo
scheduling?
> Thanks in advance.

CELL SPU is such target.

Revital

Re: Inserting Custom RTLs by the Haifa Scheduler

[Revital1 Eres]

Hello,

> I am currently working on OpenRISC port of GCC-4.0.2, and I have to
> insert a custom RTL (which gets translated to an instruction) at fixed
> parts of the code. I have created the custom instruction (by modifying
> RTL.DEF) and then put the appropritae constraints in my .md file.
>
> Now, I want this instructoin to be inserted at specific points...How
> can I do it? What function shiould I call to output this RTL?

You can use the following function to emit the new RTL instruction
you created:

emit_insn (gen_rtx_NEW_OP ...)

To insert the instruction in specific point (in this example; before insn)
you can use the following sequence:

start_sequence ();
emit_insn (gen_rtx_NEW_OP ...)
seq = get_insns ();
end_sequence ();
emit_insn_before (seq, insn);)

HTH,
Revital


>
> Any help is highly appreciated!
>
> Please CC me in the answer since I am not a subscribed member of GCC.
>
> Regards,
>
> Balaji V. Iyer.
>
> --
>
> Balaji V. Iyer
> PhD Candidate,
> Center for Efficient, Scalable and Reliable Computing,
> Department of Electrical and Computer Engineering,
> North Carolina State University.
>
>

A question regarding emitting additional info to an insn

[Revital1 Eres]

Hello,

I want print additional information for each branch insn which will be
used by the linker (for the SPU software i-cache), for example:

brsl $lr,[EMAIL PROTECTED]

and I wonder what is the best way to implement it in GCC.

I defined a new note (in reg-notes.def) which can be attached to each
branch (using add_reg_note ()) and holds that info.  I now want to print
the information of that note when emitting the branch, but I am not
sure exactly how to do that.  Should I change the instruction template
to use the reg-notes?

Thanks,
Revital

A question about cleanup_cfg ()

[Revital1 Eres]

Hello,

I have a basic-block and I want to get the last jump insn of it.
I use BB_END (bb) for that purpose.
The instruction I get is a NOTE_INSN_PROLOGUE_END which appears right
before the jump insn; and when doing NEXT_INSN for that note I get
the first insn of the next bb (code_label); which means the jump insn
was skipped...
Investigating this behavior showed that it occurs right after calling
cleanup_cfg () from cfg_layout_initialize (0) (which is been called
at the beginning of the new pass I'm working on -that is placed right
before pass_free_cfg)
It is not clear why BB_END (bb) did not return the jump insn as
expected...

Thanks,
Revital


...
(note 124 122 151 2 NOTE_INSN_PROLOGUE_END)

(jump_insn 151 124 152 2 (set (pc)
(label_ref 51)) -1 (nil)))
;; End of basic block 2 -> ( 4
...
(barrier 152 151 149)

;; Pred edge  4 [50.0%]  (can_fallthru)
(code_label 149 152 34 3 18 "" [1 uses])

[PATCH] SMS - Pass the actual schedulable rows to compute_split_row

[Revital1 Eres]

Hello,

> > Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
> PowerPC,
> > node 18 (see attachment) is in a SCC and cannot be scheduled until
> spliting
> > twice. The MII = 20 and the schedule can only  be found at II = 24.
>
> Yes, I see. This example raises a couple of issues:
>
> o The first row split (from II=20 to II=21) is miscalculated; it should
be
> row 20=0 instead of 19. Splitting row 19 cannot help schedule node 18,
and
> indeed we immediately split another row. We're now checking a small patch
> to fix this, which should save one cycle of II in the above example.

Here is the patch, on behalf of Ayal.
Passed bootstrap + regtest with SMS flags on ppc64 and bootstrap +
regtest x86.

I'll commit it later today to trunk if that's OK.

Thanks,
Revital

* modulo-sched.c (sms_schedule_by_order): Pass the actual
schedulable rows to compute_split_row.

(See attached file: patch_sms_12_3.txt)Index: modulo-sched.c
===
--- modulo-sched.c  (revision 144739)
+++ modulo-sched.c  (working copy)
@@ -1833,10 +1833,10 @@ sms_schedule_by_order (ddg_ptr g, int mi
 
   num_splits++;
   if (step == 1)
-split_row = compute_split_row (sched_nodes, start, end,
+split_row = compute_split_row (sched_nodes, start, end - 1,
ps->ii, u_node);
   else
-split_row = compute_split_row (sched_nodes, end, start,
+split_row = compute_split_row (sched_nodes, end + 1, start,
ps->ii, u_node);
 
   ps_insert_empty_row (ps, split_row, sched_nodes);

ICE in ira.c

[Revital1 Eres]

Hello,

I get the following ICE while building gcc on CELL spu; trunk -r146825.
(it passes OK on ppc)

Thanks,
Revital

gcc  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o spu-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a 
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
   -lmpfr -lgmp -rdynamic -ldl
libbackend.a(ira.o): In function `setup_cover_and_important_classes':
/home/eres/mainline_45/build/gcc/../../gcc/gcc/ira.c:759: undefined
reference to `regclass_for_constraint'
collect2: ld returned 1 exit status
make[2]: *** [cc1-dummy] Error 1

Re: ICE in ira.c

[Revital1 Eres]

Hello,
>
>   Not really an ICE!

Right, sorry about that.

Looks like the code is assuming that all backends use at
> least one define_register_constraint.  (Also, there's a missing '\n' that
> probably makes your generated definition of REG_CLASS_FROM_CONSTRAINT
look a
> bit odd!)  How about something like the attached (caution, untested -
> bootstrap still in progress)?  Let me know if it fixes the problem for
you (it
> won't get exercised on any target I'm set up to build for) and I'll
submit it
> to -patches.

Yes, the patch solves the problem (please note that I manually applied
it to my version as I've got some FAILs when applying it automatically)

Thanks,
Revital

>
> cheers,
>   DaveK
> Index: genpreds.c
> ===
> --- genpreds.c   (revision 146543)
> +++ genpreds.c   (working copy)
> @@ -1279,9 +1279,13 @@
> puts ("extern enum reg_class regclass_for_constraint "
>   "(enum constraint_num);\n"
>   "#define REG_CLASS_FROM_CONSTRAINT(c_,s_) \\\n"
> - "regclass_for_constraint (lookup_constraint (s_))\n");
> + "regclass_for_constraint (lookup_constraint (s_))\n"
> + "#define REG_CLASS_FOR_CONSTRAINT(x_) \\\n"
> + "regclass_for_constraint (x_)\n");
>else
> -   puts ("#define REG_CLASS_FROM_CONSTRAINT(c_,s_) NO_REGS");
> +   puts ("#define REG_CLASS_FROM_CONSTRAINT(c_,s_) NO_REGS\n"
> + "#define REG_CLASS_FOR_CONSTRAINT(x_) \\\n"
> + "NO_REGS\n");
>if (have_const_int_constraints)
> puts ("extern bool insn_const_int_ok_for_constraint "
>   "(HOST_WIDE_INT, enum constraint_num);\n"
> Index: ira.c
> ===
> --- ira.c   (revision 146543)
> +++ ira.c   (working copy)
> @@ -756,7 +756,7 @@
> continue;
>  #ifdef CONSTRAINT__LIMIT
>   for (j = 0; j < CONSTRAINT__LIMIT; j++)
> -   if ((int) regclass_for_constraint (j) == i)
> +   if ((int) REG_CLASS_FOR_CONSTRAINT (j) == i)
>   break;
>   if (j < CONSTRAINT__LIMIT)
> {

error in gfc_simplify_expr

[Revital1 Eres]

Hello,

I get the following error while bootstrap  trunk -r148275 on ppc.

Thanks,
Revital

/home/eres/mainline_45/build/./prev-gcc/xgcc
-B/home/eres/mainline_45/build/./prev-gcc/
-B/usr/local/powerpc64-unknown-linux-gnu/bin/
-B/usr/local/powerpc64-unknown-linux-gnu/bin/
-B/usr/local/powerpc64-unknown-linux-gnu/lib/
-isystem /usr/local/powerpc64-unknown-linux-gnu/include
-isystem /usr/local/powerpc64-unknown-linux-gnu/sys-include-c  -O3
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ifortran
-I../../gcc/gcc -I../../gcc/gcc/fortran -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/home/eres/mainline_45/build/./gmp
-I/home/eres/mainline_45/gcc/gmp -I/home/eres/mainline_45/build/./mpfr
-I/home/eres/mainline_45/gcc/mpfr  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/fortran/expr.c -o fortran/expr.o
cc1: warnings being treated as errors
../../gcc/gcc/fortran/expr.c: In function גgfc_simplify_exprג:
../../gcc/gcc/fortran/expr.c:1660:8: error: גstartג may be used
uninitialized in this function
../../gcc/gcc/fortran/expr.c:1655:15: error: גendג may be used
uninitialized in this function
make[3]: *** [fortran/expr.o] Error 1
make[3]: Leaving directory `/home/eres/mainline_45/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/eres/mainline_45/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/eres/mainline_45/build'
make: *** [bootstrap] Error 2

Re: Bootstrap failures on solaris

[Revital1 Eres]

Hello,

> i386-pc-solaris:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
> 'loop_prefetch_arrays':
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:

> format '%ld' expects type 'long int', but argument 5 has type 'long long
int'
> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
> make[3]: *** Waiting for unfinished jobs

I get this error on ppc also.

Revital
>
>
> sparc-sun-solaris2.10:
>
> /export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c: In function

> '__register_frame_table':
> /export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c:154:1:
internal
> compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2753
> Please submit a full bug report, with preprocessed source if appropriate.
>
> Anyone else seeing failures like this?
>
> Art Haas

Re: Unnecessary regmoves in modulo scheduler?

[Revital1 Eres]

Hello Bingfeng,

> I found a true register dependency is always accompanied with a
cross-iteration
> anti dependency.

When -fmodulo-sched-allow-regmoves flag is set some anti-deps edges are not
created.
Please see add_cross_iteration_register_deps () function in ddg.c.

HTH,
Revital

This should guarantee the true dependence cannot have lifetime
> longer than II.
>
> A --> B true dep (e.g., insn 36 -> insn 38 in the
DDG)
> B --> A anti dep with distance = 1(e.g., insn 38 -> insn 36 in the
DDG)
>
> The second dependdency should lead to : Sched_Time(A) + II >(=)
Sched_Time(B)
> which means Sched_Time(B) - Sched_Time(A) <(=) II and no need for reg
move.
>
> Similarly, an anti register dependency is always accompanied with a
cross-iteration
> true dependency.
>
> A --> B anti dep  (e.g., insn 36 -> insn 53 in the
DDG)
> B --> A true dep with distance = 1(e.g., insn 53 -> insn 36 in the
DDG)
> We can reach similar conclusion.
>
> I wonder what other scenario would require to generate reg moves. Am I
missing
> some obvious points? Thanks in advance.
>
>
> Cheers,
> Bingfeng Mei
>
> Broadcom UK
>
>
> DDG from sms-6.c
> SMS loop num: 1, file: sms-6.c, line: 9
> Node num: 0
> (insn 36 35 37 3 sms-6.c:11 (set (reg:SI 113)
> (mem:SI (reg:SI 108 [ ivtmp.44 ]) [4 S4 A32])) 184 {*movwsi}
(nil))
> OUT ARCS:  [36 -(A,0,0)-> 53]  [36 -(T,6,0)-> 38]
> IN ARCS:  [38 -(A,0,1)-> 36]  [53 -(T,1,1)-> 36]
> Node num: 1
> (insn 37 36 38 3 sms-6.c:11 (set (reg:SI 114)
> (mem:SI (reg:SI 109 [ ivtmp.42 ]) [5 S4 A32])) 184 {*movwsi}
(nil))
> OUT ARCS:  [37 -(A,0,0)-> 52]  [37 -(T,6,0)-> 38]
> IN ARCS:  [38 -(A,0,1)-> 37]  [52 -(T,1,1)-> 37]
> Node num: 2
> (insn 38 37 39 3 sms-6.c:11 (set (reg:SI 115)
> (mult:SI (reg:SI 113)
> (reg:SI 114))) 262 {mulsi3} (expr_list:REG_DEAD (reg:SI 114)
> (expr_list:REG_DEAD (reg:SI 113)
> (nil
> OUT ARCS:  [38 -(A,0,1)-> 37]  [38 -(A,0,1)-> 36]  [38 -(T,8,0)-> 39]
> IN ARCS:  [39 -(A,0,1)-> 38]  [36 -(T,6,0)-> 38]  [37 -(T,6,0)-> 38]
> Node num: 3
> (insn 39 38 40 3 sms-6.c:11 (set (mem:SI (reg:SI 107 [ ivtmp.45 ]) [3 S4
A32])
> (reg:SI 115)) 184 {*movwsi} (expr_list:REG_DEAD (reg:SI 115)
> (nil)))
> OUT ARCS:  [39 -(A,0,1)-> 38]  [39 -(O,1,0)-> 69]  [39 -(A,0,0)-> 54]
> IN ARCS:  [54 -(T,1,1)-> 39]  [51 -(O,1,1)-> 39]  [47 -(O,1,1)-> 39]  [43
-(O,
> 1,1)-> 39]  [38 -(T,8,0)-> 39]
> Node num: 4
> (insn 40 39 41 3 sms-6.c:12 (set (reg:SI 116)
> (mem:SI (plus:SI (reg:SI 108 [ ivtmp.44 ])
> (const_int 4 [0x4])) [4 S4 A32])) 184 {*movwsi} (nil))
> OUT ARCS:  [40 -(A,0,0)-> 53]  [40 -(T,6,0)-> 42]
> IN ARCS:  [42 -(A,0,1)-> 40]  [53 -(T,1,1)-> 40]
> Node num: 5
> (insn 41 40 42 3 sms-6.c:12 (set (reg:SI 117)
> (mem:SI (plus:SI (reg:SI 109 [ ivtmp.42 ])
> (const_int 4 [0x4])) [5 S4 A32])) 184 {*movwsi} (nil))
> OUT ARCS:  [41 -(A,0,0)-> 52]  [41 -(T,6,0)-> 42]
> IN ARCS:  [42 -(A,0,1)-> 41]  [52 -(T,1,1)-> 41]
> Node num: 6
> (insn 42 41 43 3 sms-6.c:12 (set (reg:SI 118)
> (mult:SI (reg:SI 116)
> (reg:SI 117))) 262 {mulsi3} (expr_list:REG_DEAD (reg:SI 117)
> (expr_list:REG_DEAD (reg:SI 116)
> (nil
> OUT ARCS:  [42 -(A,0,1)-> 41]  [42 -(A,0,1)-> 40]  [42 -(T,8,0)-> 43]
> IN ARCS:  [43 -(A,0,1)-> 42]  [40 -(T,6,0)-> 42]  [41 -(T,6,0)-> 42]
> Node num: 7
> (insn 43 42 44 3 sms-6.c:12 (set (mem:SI (plus:SI (reg:SI 107
[ ivtmp.45 ])
> (const_int 4 [0x4])) [3 S4 A32])
> (reg:SI 118)) 184 {*movwsi} (expr_list:REG_DEAD (reg:SI 118)
> (nil)))
> OUT ARCS:  [43 -(A,0,1)-> 42]  [43 -(O,1,0)-> 69]  [43 -(A,0,0)-> 54]
[43 -
> (O,1,1)-> 39]
> IN ARCS:  [54 -(T,1,1)-> 43]  [51 -(O,1,1)-> 43]  [47 -(O,1,1)-> 43]  [42
-(T,
> 8,0)-> 43]
> Node num: 8
> (insn 44 43 45 3 sms-6.c:13 (set (reg:SI 119)
> (mem:SI (plus:SI (reg:SI 108 [ ivtmp.44 ])
> (const_int 8 [0x8])) [4 S4 A32])) 184 {*movwsi} (nil))
> OUT ARCS:  [44 -(A,0,0)-> 53]  [44 -(T,6,0)-> 46]
> IN ARCS:  [46 -(A,0,1)-> 44]  [53 -(T,1,1)-> 44]
> Node num: 9
> (insn 45 44 46 3 sms-6.c:13 (set (reg:SI 120)
> (mem:SI (plus:SI (reg:SI 109 [ ivtmp.42 ])
> (const_int 8 [0x8])) [5 S4 A32])) 184 {*movwsi} (nil))
> OUT ARCS:  [45 -(A,0,0)-> 52]  [45 -(T,6,0)-> 46]
> IN ARCS:  [46 -(A,0,1)-> 45]  [52 -(T,1,1)-> 45]
> Node num: 10
> (insn 46 45 47 3 sms-6.c:13 (set (reg:SI 121)
> (mult:SI (reg:SI 119)
> (reg:SI 120))) 262 {mulsi3} (expr_list:REG_DEAD (reg:SI 120)
> (expr_list:REG_DEAD (reg:SI 119)
> (nil
> OUT ARCS:  [46 -(A,0,1)-> 45]  [46 -(A,0,1)-> 44]  [46 -(T,8,0)-> 47]
> IN ARCS:  [47 -(A,0,1)-> 46]  [44 -(T,6,0)-> 46]  [45 -(T,6,0)-> 46]
> Node num: 11
> (insn 47 46 48 3 sms-6.c:13 (set (mem:SI (plus:SI (reg:SI 107
[ ivtmp.45 ])
> (const_int 8 [0x8])) [3 S4 A32])
> (reg:SI 121)) 184 {*movwsi} (expr_list:REG_DEAD (re

RE: Unnecessary regmoves in modulo scheduler?

[Revital1 Eres]

Hello,

>
> Thanks. I didn't notice the option. Which approach is generally better
> according to your experience? Producing regmoves or more depedencies?

I think it depends on the target. Having reg-moves could increase
register pressure so using it on targets with small set of registers
could be painful.

Revital

>
> > -Original Message-----
> > From: Revital1 Eres [mailto:e...@il.ibm.com]
> > Sent: 23 June 2009 14:40
> > To: Bingfeng Mei
> > Cc: Ayal Zaks; gcc@gcc.gnu.org
> > Subject: Re: Unnecessary regmoves in modulo scheduler?
> >
> > Hello Bingfeng,
> >
> > > I found a true register dependency is always accompanied with a
> > cross-iteration
> > > anti dependency.
> >
> > When -fmodulo-sched-allow-regmoves flag is set some anti-deps
> > edges are not
> > created.
> > Please see add_cross_iteration_register_deps () function in ddg.c.
> >
> > HTH,
> > Revital
> >
> > This should guarantee the true dependence cannot have lifetime
> > > longer than II.
> > >
> > > A --> B true dep (e.g., insn 36 -> insn
> > 38 in the
> > DDG)
> > > B --> A anti dep with distance = 1(e.g., insn 38 ->
> > insn 36 in the
> > DDG)
> > >
> > > The second dependdency should lead to : Sched_Time(A) + II >(=)
> > Sched_Time(B)
> > > which means Sched_Time(B) - Sched_Time(A) <(=) II and no
> > need for reg
> > move.
> > >
> > > Similarly, an anti register dependency is always accompanied with a
> > cross-iteration
> > > true dependency.
> > >
> > > A --> B anti dep  (e.g., insn 36 ->
> > insn 53 in the
> > DDG)
> > > B --> A true dep with distance = 1(e.g., insn 53 ->
> > insn 36 in the
> > DDG)
> > > We can reach similar conclusion.
> > >
> > > I wonder what other scenario would require to generate reg
> > moves. Am I
> > missing
> > > some obvious points? Thanks in advance.
> > >
> > >
> > > Cheers,
> > > Bingfeng Mei
> > >
> > > Broadcom UK
> > >
> > >
> > > DDG from sms-6.c
> > > SMS loop num: 1, file: sms-6.c, line: 9
> > > Node num: 0
> > > (insn 36 35 37 3 sms-6.c:11 (set (reg:SI 113)
> > > (mem:SI (reg:SI 108 [ ivtmp.44 ]) [4 S4 A32])) 184 {*movwsi}
> > (nil))
> > > OUT ARCS:  [36 -(A,0,0)-> 53]  [36 -(T,6,0)-> 38]
> > > IN ARCS:  [38 -(A,0,1)-> 36]  [53 -(T,1,1)-> 36]
> > > Node num: 1
> > > (insn 37 36 38 3 sms-6.c:11 (set (reg:SI 114)
> > > (mem:SI (reg:SI 109 [ ivtmp.42 ]) [5 S4 A32])) 184 {*movwsi}
> > (nil))
> > > OUT ARCS:  [37 -(A,0,0)-> 52]  [37 -(T,6,0)-> 38]
> > > IN ARCS:  [38 -(A,0,1)-> 37]  [52 -(T,1,1)-> 37]
> > > Node num: 2
> > > (insn 38 37 39 3 sms-6.c:11 (set (reg:SI 115)
> > > (mult:SI (reg:SI 113)
> > > (reg:SI 114))) 262 {mulsi3} (expr_list:REG_DEAD
> > (reg:SI 114)
> > > (expr_list:REG_DEAD (reg:SI 113)
> > > (nil
> > > OUT ARCS:  [38 -(A,0,1)-> 37]  [38 -(A,0,1)-> 36]  [38
> > -(T,8,0)-> 39]
> > > IN ARCS:  [39 -(A,0,1)-> 38]  [36 -(T,6,0)-> 38]  [37 -(T,6,0)-> 38]
> > > Node num: 3
> > > (insn 39 38 40 3 sms-6.c:11 (set (mem:SI (reg:SI 107 [
> > ivtmp.45 ]) [3 S4
> > A32])
> > > (reg:SI 115)) 184 {*movwsi} (expr_list:REG_DEAD (reg:SI 115)
> > > (nil)))
> > > OUT ARCS:  [39 -(A,0,1)-> 38]  [39 -(O,1,0)-> 69]  [39
> > -(A,0,0)-> 54]
> > > IN ARCS:  [54 -(T,1,1)-> 39]  [51 -(O,1,1)-> 39]  [47
> > -(O,1,1)-> 39]  [43
> > -(O,
> > > 1,1)-> 39]  [38 -(T,8,0)-> 39]
> > > Node num: 4
> > > (insn 40 39 41 3 sms-6.c:12 (set (reg:SI 116)
> > > (mem:SI (plus:SI (reg:SI 108 [ ivtmp.44 ])
> > > (const_int 4 [0x4])) [4 S4 A32])) 184
> > {*movwsi} (nil))
> > > OUT ARCS:  [40 -(A,0,0)-> 53]  [40 -(T,6,0)-> 42]
> > > IN ARCS:  [42 -(A,0,1)-> 40]  [53 -(T,1,1)-> 40]
> > > Node num: 5
> > > (insn 41 40 42 3 sms-6.c:12 (set (reg:SI 117)
> > > (mem:SI (plus:SI (reg:SI 109 [ ivtmp.42 ])
> > > (const_int 4 [0x4])) [5 S4 A32])) 184
> > {*movwsi} (nil))
> > > OUT ARCS:  [41 -(A,0,0)-> 52]  [41 -(T,6,0)-> 42]
> > > IN ARCS:  [42 -(A,0,1)-> 41]  [52 -(T,1,1)-> 41]
&

Re: Compiling gcc 4.4.0 for Cell

[Revital1 Eres]

Hello,

> I am trying to compile gcc 4.4.0 for the Cell processor for my google
> summer of code project (GCC's OpenCL implementation starting point).
>
> I have used OpenMP for some things and now I am trying to compile
> everything on the Cell.  OpenMP is supported in the ppu-gcc 4.1.0 so
> I am trying to upgrade my PS3 to gcc 4.4.0.

You can configure PPU like any other 64-bit PowerPC processors,
for example, by specifying --target=powerpc64-unknown-linux-gnu.

HTH,
Revital

>
> I did
> #ppu-gcc -v
> and that got me how gcc was configured for the cell.
>
> So I pasted most of it into the shell:
>
> [r...@ps3 gcc-4.4.0]# ./configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --with-as=/usr/bin/ppu-as --with-ld=/usr/bin/ppu-ld --enable-threads
> --with-system-zlib --disable-checking --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-languages=c,c++,fortran,ada
> --disable-nls --enable-clocale=gnu
> --enable-version-specific-runtime-libs --with-long-double-128
> --program-prefix=ppu- --disable-bootstrap --host=ppu
> --build=powerpc64-unknown-linux-gnu --target=ppu
> checking build system type... powerpc64-unknown-linux-gnu
> checking host system type... Invalid configuration `ppu': machine
> `ppu' not recognized
> configure: error: /bin/sh ./config.sub ppu failed
> [r...@ps3 gcc-4.4.0]#
>
> Anyone have any tips to get this compiled?
>
> Thanks.
>
> Sincererly,
> Phil Pratt-Szeliga

A question regarding bundling and NOPs insertion for VLIW architecture

[Revital1 Eres]

Hello,

I have a question regarding the process of bundling and NOPs insertion for
VLIW architecture
and I appreciate your answer:

I am calling the second scheduler from the machine reorg pass; similar to
what is done for IA64.
I now want to handle the bundling and NOPs insertion for VLIW architecture
with issue rate of 4
and I want to make sure I understand the process:

IIUC I can use the insns with TImode that the scheduler marked to indicate
a new cycle, so the
the question is how many nops to insert after that cycle, if any.
I noticed the following approach that was used in c6x which is mentioned
in:
http://archiv.tu-chemnitz.de/pub/2004/0176/data/index.html

"NOP Insertion and Parallel Scheduling
If the scheduler is run, it checks dependencies and tries to schedule the
instructions as to
minimize the processing cycles. The hooks TARGET_SCHED_REORDER(2) are
considered
to reorder the instructions in the ready cue in case the back end wants to
override the
default rules. I used the hooks to memorize the program cycle the
instruction is scheduled.
This value is stored in a hash table I created for that purpose. From the
cycle information
I can later determine how many NOPs have to be inserted between two
instructions. This
value then overrides the attribute value."

IA64 seems to have much more complicated approach for the bundling and NOPs
insertion and I wonder
if the reason is due to IA64 specific issues? or there is something I'm
missing in the approach
mentioned above?

Thanks in advance,
Revital

Help with expanding compare

[Revital1 Eres]

Hello,

I am using current mainline to compile a testcase which contains a loop.
The target I'm working on supports cmpsi pattern.

While expanding the loop condition I get that do_compare_rtx_and_jump ()
and
 do_jump_by_parts_greater_rtx () call each other repeatedly.

The test I'm compiling passes OK when using GCC 4.4.  Looking into the
difference between the two versions that might caused this problem;
I see that in GCC4.4 can_compare_p () asks if the target supports
cmp_optab. while GCC4.6 does not ask for this opcode and thus IIUC causes
the later call to do_jump_by_parts_greater_rtx ().

I appreciate any help with this problem.

Thanks,
Revital

Re: Help with expanding compare

[Revital1 Eres]

Hello,

Just did so... :-)
and it indeed solves this.

Thanks,
Revital




From:   Paolo Bonzini 
To: Revital1 Eres/Haifa/i...@ibmil
Cc: gcc@gcc.gnu.org
Date:   25/05/2010 03:57 PM
Subject:Re: Help with expanding compare
Sent by:Paolo Bonzini 



On 05/25/2010 12:13 PM, Revital1 Eres wrote:
>
> Hello,
>
> I am using current mainline to compile a testcase which contains a loop.
> The target I'm working on supports cmpsi pattern.
>
> While expanding the loop condition I get that do_compare_rtx_and_jump ()
> and
>   do_jump_by_parts_greater_rtx () call each other repeatedly.
>
> The test I'm compiling passes OK when using GCC 4.4.  Looking into the
> difference between the two versions that might caused this problem;
> I see that in GCC4.4 can_compare_p () asks if the target supports
> cmp_optab. while GCC4.6 does not ask for this opcode and thus IIUC causes
> the later call to do_jump_by_parts_greater_rtx ().

Have you converted cmpsi to cbranchsi4?

Paolo

Re: Question about Machine Description

[Revital1 Eres]

Hello,

> I want to limit the size of immediate field of some operation.

I think you can look at SIGNED_INT_FITS_N_BITS definition at
config/crx/crx.c
for such example.
You can write a predicate like the following; and use it when describing
the immediate
operand in the md file.

(define_predicate "s24bits_operand"
  (match_code "const_int")
  {
return (SIGNED_INT_FITS_N_BITS(INTVAL(op), 24)) ? 1 : 0;
  }
)

Thanks,
Revital

Help with reload

[Revital1 Eres]

Hello,

I have a question regarding code generation for a new target I'm working
on.
I am using GCC 4.6.

In reload pass  the following first instruction is replaced with the
second one after spilling reg 182 to the stack.  The problem is that
the generated new instruction does not have a valid address format and
I'm not sure why it was considered as a valid replacement.
Any help on how to resolve this is appreciated.

(insn 282 150 151 13 jctrans.c:109 (set (reg:SI 12 r12)
(mem/s:SI (plus:SI (reg/v/f:SI 182 [ incomp ])
(const_int 8 [0x8])) [6 *incomp_85 S4 A32])) -1 (nil))

(insn 282 150 151 13 jctrans.c:109 (set (reg:SI 12 r12)
(mem/s:SI (plus:SI (mem/c:SI (plus:SI (reg/f:SI 63 r63)
(const_int -12 [0xfff4])) [56 %sfp+-12 S4 A32])
(const_int 8 [0x8])) [6 *incomp_85 S4 A32])) -1 (nil))

Thanks,
Revital

A question about mov pattern

[Revital1 Eres]

Hello,

In the new target I'm working on there are branch regs and gprs.
The loads and store instructions are only to/from the gprs, so if a
branch reg needs to be spilled it first needs to be moved to a gpr and
then stored to memory.  I've implemented mov pattern in the machine
description file for the gprs and a mov pattern between gprs and branch
regs; however I'm am not sure if I need to add more to model the behavior
described above and if so how to do it.

Thanks,
Revital

A question about doloop

[Revital1 Eres]

Hello,

Doloop optimization fails to be applied on the following kernel from
tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
iteration
case' message; taken from the loop2_doloop dump. (please see below).
With an older version of gcc (-r 146278) doloop succeeded to be applied
and I appreciate an explanation about the change of behavior.

Thanks,
Revital

The kernel:

  unsigned int i, n = size;
  int changed = 0;

  for (i = 0; i < n; i++)
{
  const int tmp = *ap++ | (*bp++ & *cp++);
  changed |= *dstp ^ tmp;
  *dstp++ = tmp;
}

The messages from loop2_doloop dump:

Doloop: Possible infinite iteration case.
Doloop: The loop is not suitable.


Loop 1 is simple:
  simple exit 4 -> 5
  infinite if: (expr_list:REG_DEP_TRUE (ne:SI (and:DI (minus:DI (plus:DI
(ashift:DI (reg:DI 200)
(const_int 2 [0x2]))
(reg/v/f:DI 194 [ ap ]))
(reg:DI 168 [ ivtmp.19 ]))
(const_int 3 [0x3]))
(const_int 0 [0]))
(nil))

A question about MAX_EXPR

[Revital1 Eres]

Hello,

I'm compiling the following test with GCC 4.6.0 and I do not see that
MAX_EXPR is generated for (num)<0)?0:(num).
With GCC 4.3.2 it is generated OK in original dump (both compilation were
made with -O3).  Is there a flag I should use to generate MAX_EXPR
with GCC 4.6.0?

Thanks,
Revital

#define TEST(num) (unsigned char)(((num)>0xFF)?0xff:(((num)<0)?0:(num)))

int foo(const unsigned char *tmp, int i, int val)
{
return TEST(tmp[i] + val);
}

Question about Doloop

[Revital1 Eres]

Hello,

Doloop optimization fails to be applied on the following inner loop
when compiling for PowerPC  (GCC -r162294) due to:

Doloop: number of iterations too costly to compute.

I do not understand why as the number of iterations is max_cols and I
appreciate an explanation.

Thanks,
Revital

 11   while (--max_rows >= 0)
 12 {
 13   inptr = *inbuf++;
 14   outp = outbuf[0][rows];
 15   rows++;
 16
 17   for (y = 0; y < max_cols; y++)
 18 {
 19   k = ((int) (inptr[0]));
 20   inptr += 3;
 21
 22   outp[y] = (unsigned char) ((inarr[k]) >> 16);
 23 }
 24 }


>From Doloop dump:

Analyzing operand (reg/f:DI 246 [ D.2082 ]) of insn (insn 118 116 119 5
test1.c:17 (set (reg:CC 272)
(compare:CC (reg/v/f:DI 199 [ inptr ])
(reg/f:DI 246 [ D.2082 ]))) 535 {*cmpdi_internal1}
(expr_list:REG_DEAD (reg/f:DI 246 [ D.2082 ])
(nil)))
  invariant (reg/f:DI 246 [ D.2082 ]) (in DI)
Loop 2 is simple:
  simple exit 5 -> 6
  number of iterations: (mult:DI (plus:DI (minus:DI (reg/f:DI 246
[ D.2082 ])
(reg/v/f:DI 199 [ inptr ]))
(const_int -3 [0xfffd]))
(const_int -6148914691236517205 [0xaaab]))
  upper bound: -1
Doloop: number of iterations too costly to compute.


 (See attached file: test1.c)

test1.c
Description: Binary data

Question about alias check in ddg.c

[Revital1 Eres]

Hello,

When trying to compile the following loop with GCC -r164298 with modulo
scheduling pass enabled on PowerPC I get that the inter loop edges
between the memory instructions are created in the DDG although the
following check in ddg.c exists:

static void
add_inter_loop_mem_dep (ddg_ptr g, ddg_node_ptr from, ddg_node_ptr to)
{
  if (!insns_may_alias_p (from->insn, to->insn))
 return;

With GCC -r146278 the edges are not created in the DDG.
Looking more closely into the code I see the following differences in ddg.c
between the GCC versions:

The new version of GCC contains:

add_inter_loop_mem_dep ()  -> ...-> may_alias_p()

while with GCC -r146278:

add_inter_loop_mem_dep () -> ... -> insn_alias_sets_conflict_p()

I do not understand this behavior and I appreciate an explanation.

Thanks,
Revital


void foo( int * __restrict__ dst,  int * __restrict__ src1,
  int * __restrict__ src2)
{
int x, y;

   for( x = 0; x < 100; x+=1 )
{
dst[x] = ( src1[x] * src2[x] ) ;
}
}

A question about using restrict

[Revital1 Eres]

Hello,

I have the loop below and I want to pass to gcc that src1 and src2 never
alias with dst; so I used the restrict keyword as below; however I still
see that there are dependence edges between dst and src1 and src2 in
the DDG created by SMS and I wonder how can I resolve this.
(I used GCC -v167637 and compiled for powerpc)

Thanks,
Revital

Original version:

void foo(unsigned char  ***dst,
unsigned char *src1,
unsigned char  *src2, int row)
{
int x;

for( x = 0; x < 100; x+=1)
  {
dst[0][row][x] = ( src1[x] * src2[x]);
  }
}

version 1 with restrict:

void foo(unsigned char  ***__restrict__ dst,
unsigned char *__restrict__ src1,
unsigned char  *__restrict__ src2, int row)
{
int x;

for( x = 0; x < 100; x+=1)
  {
dst[0][row][x] = ( src1[x] * src2[x]);
  }
}

version 2 with restrict:

void
foo(unsigned char  *** __restrict__ dst,
unsigned char * __restrict__ src1,
unsigned char  * __restrict__ src2, int row)
{
int x;
unsigned char  **__restrict__ dst1 = dst[0];
unsigned char  * __restrict__ dst2 = dst1[row];

for( x = 0; x < 100; x+=1)
  {
dst2[x] = (src1[x] * src2[x]);
  }
}

RE: A question about using restrict

[Revital1 Eres]

Hello Bingfeng,

Thanks for your reply! I would be very interested to try your patch.

Revital




From:   "Bingfeng Mei" 
To:     Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"

Date:   13/12/2010 12:20 PM
Subject:RE: A question about using restrict



Hi, Revital,
Sorry for late reply. I think you can write following code
according to C99 standard to make sure src1/src2 don't alias
with dst. However, current GCC support for restrict is still
quite weak. The restrict info tends to be lost in all optimizations,
especially ivopts. You won't get the intended result. I have some
internal patch for 4.5 to track the source of a pointer.
It is not a very efficient implementation but works for us so far.
I can send to you if you are interested.

void
foo(unsigned char  *** dst,
unsigned char * __restrict__ src1,
unsigned char  * __restrict__ src2, int row)
{
int x;
unsigned char  * __restrict__ dst2 = dst[0][row];

for( x = 0; x < 100; x+=1)
  {
dst2[x] = (src1[x] * src2[x]);
  }
}

Cheers,
Bingfeng

> -Original Message-
> From: Revital1 Eres [mailto:e...@il.ibm.com]
> Sent: 13 December 2010 07:59
> To: gcc@gcc.gnu.org
> Cc: Bingfeng Mei
> Subject: A question about using restrict
>
>
> Hello,
>
> I have the loop below and I want to pass to gcc that src1 and src2
> never
> alias with dst; so I used the restrict keyword as below; however I
> still
> see that there are dependence edges between dst and src1 and src2 in
> the DDG created by SMS and I wonder how can I resolve this.
> (I used GCC -v167637 and compiled for powerpc)
>
> Thanks,
> Revital
>
> Original version:
>
> void foo(unsigned char  ***dst,
> unsigned char *src1,
> unsigned char  *src2, int row)
> {
> int x;
>
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
>
> version 1 with restrict:
>
> void foo(unsigned char  ***__restrict__ dst,
> unsigned char *__restrict__ src1,
> unsigned char  *__restrict__ src2, int row)
> {
> int x;
>
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
>
> version 2 with restrict:
>
> void
> foo(unsigned char  *** __restrict__ dst,
> unsigned char * __restrict__ src1,
> unsigned char  * __restrict__ src2, int row)
> {
> int x;
> unsigned char  **__restrict__ dst1 = dst[0];
> unsigned char  * __restrict__ dst2 = dst1[row];
>
> for( x = 0; x < 100; x+=1)
>   {
> dst2[x] = (src1[x] * src2[x]);
>   }
> }
>
>

Re: [ARM] Implementing doloop pattern

[Revital1 Eres]

Hello,

The attached patch is my latest attempt to model doloop for arm.
I followed Chung-Lin Tang suggestion and used subs+jump similar to your
patch.
On crotex-A8 I see gain of 29% on autocor benchmark (telecom suite) with
SMS using the following flags: -fmodulo-sched-allow-regmoves
-funsafe-loop-optimizations -fmodulo-sched   -fno-auto-inc-dec
-fdump-rtl-sms -mthumb  -mcpu=cortex-a8 -O3. (compare to using only
-mthumb  -mcpu=cortex-a8 -O3)

I have not fully tested the patch and it's not in the proper format of
submission yet.

Thanks,
Revital

(See attached file: patch_arm_doloop.txt)



From:   Roman Zhuykov 
To: gcc@gcc.gnu.org
Cc: d...@ispras.ru
Date:   30/12/2010 04:04 PM
Subject:[ARM] Implementing doloop pattern
Sent by:gcc-ow...@gcc.gnu.org



Hello!

The main idea of the work described below was to estimate speedup we can
gain from SMS on ARM.  SMS depends on doloop_end pattern and there is no
appropriate instruction on ARM.  We decided to create a "fake"
doloop_end pattern on ARM using a pair of "subs" and "bne" assembler
instructions.  In implementation we used ideas from machine description
files of other architectures, e. g. spu, which expands doloop_end
pattern only when SMS is enabled.  The patch is attached.

This patch allows to use any possible register for the doloop pattern.
It was tested on trunk snapshot from 30 Aug 2010.  It works fine on
several small examples, but gives an ICE on sqlite-amalgamation-3.6.1
source:
sqlite3.c: In function 'sqlite3WhereBegin':
sqlite3.c:76683:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1020

ICE happens in ira pass, when cleanup_cfg is called at the end or ira.

The "bad" instruction looks like
(jump_insn 3601 628 4065 76 (parallel [
 (set (pc)
 (if_then_else (ne (mem/c:SI (plus:SI (reg/f:SI 13 sp)
 (const_int 36 [0x24])) [105 %sfp+-916
S4 A32])
 (const_int 1 [0x1]))
 (label_ref 3600)
 (pc)))
 (set (mem/c:SI (plus:SI (reg/f:SI 13 sp)
 (const_int 36 [0x24])) [105 %sfp+-916 S4 A32])
 (plus:SI (mem/c:SI (plus:SI (reg/f:SI 13 sp)
 (const_int 36 [0x24])) [105 %sfp+-916 S4 A32])
 (const_int -1 [0x])))
 ]) sqlite3.c:75235 328 {doloop_end_internal}
  (expr_list:REG_BR_PROB (const_int 9100 [0x238c])
 (nil))
  -> 3600)

So, the problem seems to be with ira.  Memory is used instead of a
register to store doloop counter.  We tried to fix this by explicitly
specifying hard register (r5) for doloop pattern.  The fixed version
seems to work, but this doesn't look like a proper fix.  On trunk
snapshot from 17 Dec 2010 the ICE described above have disappeared, but
probably it's just a coincidence, and it will shop up anyway on some
other test case.

The r5-fix shows the following results (compare "-O2 -fno-auto-inc-dec
-fmodulo-sched" vs "-O2 -fno-auto-inc-dec").
Aburto benchmarks: heapsort and matmult - 3% speedup. nsieve - 7% slowdown.
Other aburto tests, sqlite tests and libevas rasterization library
(expedite testsuite) show around zero results.

A motivating example shows about 23% speedup:

char scal (int n, char *a, char *b)
{
   int i;
   char s = 0;
   for (i = 0; i < n; i++)
 s += a[i] * b[i];
   return s;
}

We have analyzed SMS results, and can conclude that if SMS has
successfully built a schedule for the loop we usually gain a speedup,
and when SMS fails, we often have some slowdown, which have appeared
because of do-loop conversion.

The questions are:
How to properly fix the ICE described?
Do you think this approach (after the fixes) can make its way into trunk?

Happy holidays!
--
Roman Zhuykov

[attachment "sms-doloop-any-reg.diff" deleted by Revital1 Eres/Haifa/IBM]Index: modulo-sched.c
===
--- modulo-sched.c  (revision 167637)
+++ modulo-sched.c  (working copy)
@@ -1021,7 +1021,8 @@ sms_schedule (void)
 if (CALL_P (insn)
 || BARRIER_P (insn)
 || (NONDEBUG_INSN_P (insn) && !JUMP_P (insn)
-&& !single_set (insn) && GET_CODE (PATTERN (insn)) != USE)
+&& !single_set (insn) && GET_CODE (PATTERN (insn)) != USE
+&& !reg_mentioned_p (count_reg, insn))
 || (FIND_REG_INC_NOTE (insn, NULL_RTX) != 0)
 || (INSN_P (insn) && (set = single_set (insn))
 && GET_CODE (SET_DEST (set)) == SUBREG))
Index: loop-doloop.c
===
--- loop-doloop.c   (revision 167637)
+++ loop-doloop.c   (working copy)
@@ -96,7 +96,15 @@ doloop_condition_

Re: [ARM] Implementing doloop pattern

[Revital1 Eres]

Hello,

>
> @@ -162,6 +175,7 @@ doloop_condition_get (rtx doloop_pat)
>  return 0;
>
>if ((XEXP (condition, 0) == reg)
> +  || (REGNO (XEXP (condition, 0)) == CC_REGNUM)
>|| (GET_CODE (XEXP (condition, 0)) == PLUS
>&& XEXP (XEXP (condition, 0), 0) == reg))
>
> You can't depend on CC_REGNUM in generic code.  That's part of the
> private machine description for ARM.  Other cores have different ways of
> representing condition codes.
>
> R.

Yes, thanks, I found that out when testing the patch on PowerPC.
Attached is a newer version of the patch which is currently
under testing.

Thanks,
Revital


(See attached file: patch_arm_doloop_5.txt)Index: modulo-sched.c
===
--- modulo-sched.c  (revision 168397)
+++ modulo-sched.c  (working copy)
@@ -1021,7 +1021,8 @@ sms_schedule (void)
 if (CALL_P (insn)
 || BARRIER_P (insn)
 || (NONDEBUG_INSN_P (insn) && !JUMP_P (insn)
-&& !single_set (insn) && GET_CODE (PATTERN (insn)) != USE)
+&& !single_set (insn) && GET_CODE (PATTERN (insn)) != USE
+&& !reg_mentioned_p (count_reg, insn))
 || (FIND_REG_INC_NOTE (insn, NULL_RTX) != 0)
 || (INSN_P (insn) && (set = single_set (insn))
 && GET_CODE (SET_DEST (set)) == SUBREG))
Index: loop-doloop.c
===
--- loop-doloop.c   (revision 168397)
+++ loop-doloop.c   (working copy)
@@ -78,6 +78,8 @@ doloop_condition_get (rtx doloop_pat)
   rtx inc_src;
   rtx condition;
   rtx pattern;
+  rtx cc_reg = NULL_RTX;
+  rtx reg_orig;
 
   /* The canonical doloop pattern we expect has one of the following
  forms:
@@ -96,7 +98,16 @@ doloop_condition_get (rtx doloop_pat)
  2)  (set (reg) (plus (reg) (const_int -1))
  (set (pc) (if_then_else (reg != 0)
 (label_ref (label))
-(pc))).  */
+(pc))).  
+
+ Some targets (ARM) do the comparison before the branch, as in the
+ folloring form:
+
+ 3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
+   (set (reg) (plus (reg) (const_int -1)))])
+(set (pc) (if_then_else (NE == cc)
+(label_ref (label))
+(pc))) */
 
   pattern = PATTERN (doloop_pat);
 
@@ -104,14 +115,42 @@ doloop_condition_get (rtx doloop_pat)
 {
   rtx cond;
   rtx prev_insn = prev_nondebug_insn (doloop_pat);
+  rtx src_orig;
+  rtx cmp_orig;
 
-  /* We expect the decrement to immediately precede the branch.  */
+  /* In case the pattern is not PARALLEL we expect two forms
+of doloop which are cases 2) and 3) above: in case 2) the
+decrement is immediately precedes the branch. while in case
+3) the compre and decrement instructions immediately precede
+the branch.  */
 
   if (prev_insn == NULL_RTX || !INSN_P (prev_insn))
 return 0;
 
   cmp = pattern;
-  inc = PATTERN (PREV_INSN (doloop_pat));
+  if (GET_CODE (PATTERN (prev_insn)) == PARALLEL)
+{
+ /* The third case: the compre and decrement instructions
+immediately precede the branch.  */
+ cmp_orig = XVECEXP (PATTERN (prev_insn), 0, 0);
+ if (GET_CODE (cmp_orig) != SET)
+   return 0;
+ if (GET_CODE (SET_SRC (cmp_orig)) != COMPARE)
+   return 0;
+ src_orig = XEXP (SET_SRC (cmp_orig), 0);
+ if (XEXP (SET_SRC (cmp_orig), 1) != const0_rtx 
+ || GET_CODE (src_orig) != PLUS)
+   return 0;
+ reg_orig = XEXP (src_orig, 0);
+ if (XEXP (src_orig, 1) != GEN_INT (-1) 
+ || !REG_P (reg_orig))
+   return 0;
+ cc_reg = SET_DEST (cmp_orig);
+ 
+ inc = XVECEXP (PATTERN (prev_insn), 0, 1);
+   }
+  else
+inc = PATTERN (PREV_INSN (doloop_pat));
   /* We expect the condition to be of the form (reg != 0)  */
   cond = XEXP (SET_SRC (cmp), 0);
   if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
@@ -162,6 +201,9 @@ doloop_condition_get (rtx doloop_pat)
 return 0;
 
   if ((XEXP (condition, 0) == reg)
+  || ((cc_reg != NULL_RTX)
+ && (XEXP (condition, 0) == cc_reg)
+ && (reg_orig == reg))
   || (GET_CODE (XEXP (condition, 0)) == PLUS
   && XEXP (XEXP (condition, 0), 0) == reg))
{
@@ -181,7 +223,24 @@ doloop_condition_get (rtx doloop_pat)
  (set (reg) (plus (reg) (const_int -1)))
  (additional clobbers and uses)])
 
- So we return that form instead.
+For the third form we expect:
+
+(parallel [(set (cc) (compare ((plus (reg) (const_int -1)), 0))
+   (set (reg) (plus (reg) (const_int -1)))])
+

A question concering GCC testsuite

[Revital1 Eres]

Hello,

I appreciate it if someone could explain what is the difference between
gcc.c-torture library and gcc.dg library under the testsuite directory.

Thanks,
Revital

A question regarding -fwrapv flag

[Revital1 Eres]

Hello,

I am running the attached testcase (inspired from vect/vect-reduc-3.c
testcase) with -O3 -fwrapv on powerpc64-linux with trunk 4.4.

Here is a snippet from the testcase:

...

  unsigned short ub[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
  unsigned short uc[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
  unsigned short udiff;


  udiff = 0;
  for (i = 0; i < n; i++) {,
udiff += (ub[i] - uc[i]);,
  }

 ...

It seems that the use of -fwrapv flag causes part of the variables to};
be converted to short and I do not understand why.

Snippet from the .gimple dump file:

  i.2 = i;
  D.1654 = ub[i.2];
  i.2 = i;
  D.1655 = uc[i.2];
  D.1656 = D.1654 - D.1655;
  D.1657 = (short int) D.1656;
  udiff.3 = (short int) udiff;
  D.1659 = D.1657 + udiff.3;
  udiff = (short unsigned int) D.1659;

Thanks,
Revital

(See attached file: test-2.c)

test-2.c
Description: Binary data

Bootstrap failure on powerpc64-linux

[Revital1 Eres]

Hello,

I get the following bootstrap failure on powerpc64-linux, trunk r132684

configure with:
--with-cpu=default32  --enable-checking --enable-bootstrap

Revital

libtool: compile:  /home/revitale/mainline_branch/build/./gcc/xgcc
-B/home/revitale/mainline_branch/build/./gcc/
-B/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/bin/
-B/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/lib/
-isystem 
/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/include

-isystem 
/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/sys-include
 -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I.
-iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc
-I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2
-MT maxloc1_4_r16.lo -MD -MP -MF .deps/maxloc1_4_r16.Tpo
-c ../../../gcc/libgfortran/generated/maxloc1_4_r16.c  -fPIC -DPIC
-o .libs/maxloc1_4_r16.o
../../../gcc/libgfortran/generated/maxloc1_4_r16.c: In function
'mmaxloc1_4_r16':
../../../gcc/libgfortran/generated/maxloc1_4_r16.c:220: internal compiler
error: in memory_address, at explow.c:492
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [maxloc1_4_r16.lo] Error 1
make[3]: Leaving directory
`/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/revitale/mainline_branch/build/powerpc64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/revitale/mainline_branch/build'

Re: Supporting 'MAC' instruction on gcc v4.1.1

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 11/05/2007 15:26:16:

> Hello all,
>
> I am working on gcc v4.1.1 for a non-gcc target. I want to support
> 'MAC' instruction
> (mac OP1, OP2, OP3  =>  OP3 += OP1 * OP2).
>

http://gcc.gnu.org/ml/gcc/2007-05/msg00114.html seems relevant to your
problem.

Revital
>
>
> Regards,
> Rahul

Re: help required for upgradation of gcc-4.1.1

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 28/05/2007 09:05:24:


>
> Can you help to upgrade the gcc to 4.1.1 by providing the steps and
> procedure etc

I think you should try the gcc-help mailing list.

Revital

Help in understanding ccp propagator

[Revital1 Eres]

Hello,

I will greatly appreciate any suggestions regarding the following
problem I have with the ccp propagator. I am testing the new store
ccp patch which propagates constants by walking the virtual use-def
chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
encountered the following problem while testing tree_join.cc file which
is under libstdc++-v3 testsuite:

The final propagator replaces the right operand (D.65705_98) in the
following if condition with a constant zero which causes the program to be
aborted as i0_62 is not always zero:

  # i0_62 = PHI 
:;
  D.61410.first = i0_62;
...
   D.65705_98 = D.61410.first;
-  if (D.65704_96 >= 0)
+  if (D.65704_96 >= D.65705_98)
 goto ;
   else
 goto ;

Tracing the execution of the propagator it seems that the if statement
is first been propogated with zero after simulating the execution; but not
updated after the lattice value of the variables it depends on changed.

Here is the scenario of the propagator:

1) D.61410.first is been updated to zero:

19921 Visiting PHI node: i0_62 = PHI 
19922 Argument #0 (29 -> 4 not executable)
19923
19924 Argument #1 (3 -> 4 executable)
19925 0   Value: CONSTANT 0
19926
19927 PHI node value: CONSTANT 0
19928
19929 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
19930
19931 Visiting statement:
19932 D.61410.first = i0_62;
19933
19934 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
19935

2) D.65705_98 is been upadted to zero:

20235 Visiting statement:
20236 D.65705_98 = D.61410.first;
20237
20238 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
20239
20240 Visiting statement:
20241 if (D.65704_96 >= D.65705_98)


3) D.61410.first latice value changed to VARYING.

20360 Simulating statement (from ssa_edges): D.61410.first = i0_62;
20361
20362 Visiting statement:
20363 D.61410.first = i0_62;
20364
20365 Lattice value changed to VARYING.  Adding SSA edges to worklist.

4) if D.65705_98 is been replaced to zero:

25422 Substituing values and folding statements
25423
25424 Folded statement Folded statement: if (D.65704_96 >= D.65705_98)
25425 into: if (D.65704_96 >= 0)

I am not sure why after the lattice value of D.61410.first has been
changed to VARYING D.65705_98 and the if statement is not been updated
as well.

Thanks,
Revital

Re: Help in understanding ccp propagator

[Revital1 Eres]

> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
> > encountered the following problem while testing tree_join.cc file which
> > is under libstdc++-v3 testsuite:
>
>
> BTW, a lot of these will be caught with the new VN i posted, whicih
> should be reviewed and go in soon.

Thanks, should it handle cases like the one in the following example -
http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt?  I tried it with
the VN patch but it seems to not caught it...

> > The final propagator replaces the right operand (D.65705_98) in the
> > following if condition with a constant zero which causes the program to
be
> > aborted as i0_62 is not always zero:
> >
> >   # i0_62 = PHI 
> > :;
> >   D.61410.first = i0_62;
> > ...
> >D.65705_98 = D.61410.first;
> > -  if (D.65704_96 >= 0)
> > +  if (D.65704_96 >= D.65705_98)
> >  goto ;
> >else
> >  goto ;
> >
> > Tracing the execution of the propagator it seems that the if statement
> > is first been propogated with zero after simulating the execution; but
not
> > updated after the lattice value of the variables it depends on changed.
>
> Does your store CPP properly say the vdefs have changed when a
> statement's lattice value changes?

I am not sure I understand.  The new patch uses the infrastructure of
the propagator and I do not see an indication in the dumps for vdefs
update after the lattice value is changed:

19930
19931 Visiting statement:
19932 D.61410.first = i0_62;
19933
19934 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
19935

Thanks again fo your help,
Revital

Bootstrap failure on ppc64

[Revital1 Eres]

Hello,

The following error is received on  ppc64.

Thanks,
Revital

symtab.o -MT symtab.o -MMD -MP -MF .deps/symtab.Po
../../gcc/libcpp/symtab.c
/home/eres/mainline_lim/build/./prev-gcc/xgcc
-B/home/eres/mainline_lim/build/./prev-gcc/
-B/home/eres/mainline_lim/build/powerpc64-unknown-linux-gnu/bin/
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -O3 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Werror
-I../../gcc/libcpp -I. -I../../gcc/libcpp/../include
-I../../gcc/libcpp/include  -c -o traditional.o -MT traditional.o -MMD -MP
-MF .deps/traditional.Po ../../gcc/libcpp/traditional.c
cc1: warnings being treated as errors
../../gcc/libcpp/traditional.c: In function ג_cpp_scan_out_logical_lineג:
../../gcc/libcpp/traditional.c:349: error: גfmacro.argsג may be used
uninitialized in this function
../../gcc/libcpp/traditional.c:349: error: גfmacro.nodeג may be used
uninitialized in this function
../../gcc/libcpp/traditional.c:349: error: גfmacro.offsetג may be used
uninitialized in this function
../../gcc/libcpp/traditional.c:349: error: גfmacro.argcג may be used
uninitialized in this function
../../gcc/libcpp/traditional.c:349: error: גfmacro.lineג may be used
uninitialized in this function
make[3]: *** [traditional.o] Error 1
make[3]: Leaving directory `/home/eres/mainline_lim/build/libcpp'
make[2]: *** [all-stage2-libcpp] Error 2
make[2]: Leaving directory `/home/eres/mainline_lim/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/eres/mainline_lim/build'
make: *** [bootstrap] Error 2

Re: Help in understanding ccp propagator

[Revital1 Eres]

> I can modify it to catch it pretty easily, just walk back a few vuses
> if the current set of vuses is defined by something that does not
> actually touch our offset.

This sounds like what I am trying to do in ccp...

> >
> > I am not sure I understand.  The new patch uses the infrastructure of
> > the propagator and I do not see an indication in the dumps for vdefs
> > update after the lattice value is changed:
> >
> > 19930
> > 19931 Visiting statement:
> > 19932 D.61410.first = i0_62;
> > 19933
> > 19934 Lattice value changed to CONSTANT 0.  Adding SSA edges to
worklist.
> > 19935
> >
> > Thanks again fo your help,
> > Revital
>
> So uh, how do you expect the propagator to notice when the used
> variables have changed if the things the vdefs produced by
> D.61410.first are not marked as change (so that the immediate uses of
> it get processed).
>
> You will need to add this if it is not there already.
>
>
> Normally, the propagator says "oh, the lattice value of D_64 changed,
> let me mark all it's immediate uses for reprocessing". The only thing
> that links memory defs to memory uses is the vdef/vuses, so you will
> have to be able to process and mark those

I thought the engine suppose to take care of that.  I do not understand
why this case is different from other cases where we propagate for
vdefs...

Thanks again,
Revital

Re: vector compare

[Revital1 Eres]

> Could someone tell me how to do vector compare in generic way?

AFAICT every target which supports vector operations has it's own
list of built-in function for vector comparison.  For example, Altivec
has vec_cmpgt and other built-ins for vector compare instructions.
(see altivec.h file for the list of built-ins)

Revital

>
>
> Look forward to hearing from you
>
>
> Maggie
>
>

Help understanding tree-affine.c

[Revital1 Eres]

Hello,

I am trying to understand the usage of some functions in tree-affine.c
file and I appreciate your help.

For example; for the two memory accesses
 arr[b+8].X  and  arr[b+9].X, how does their affine combinations
will look like after executing the following sequence of operation?
(taken from http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02605.html)

get_inner_reference_aff (mem1, &off1, &size1);
get_inner_reference_aff (mem2, &off2, &size2);
aff_combination_expand (&off1, ttae_cache);
aff_combination_expand (&off2, ttae_cache);
aff_combination_scale (&off1, double_int_minus_one);
aff_combination_add (&off2, &off1);

Also, why does diff->n is an indication for the fact that two memory
accesses can overlap in the following snippet taken from the above link?

static bool
cannot_overlap_p (aff_tree *diff, double_int size1, double_int size2)
{
  double_int d, bound;

  /* Unless the difference is a constant, we fail.  */
  if (diff->n != 0)
return false;

Thanks in advance,
Revital

Re: Help in understanding ccp propagator

[Revital1 Eres]

> The engine only knew how to propagate cases that always make the same
> set of vdef/vuses, so it was safe to only tell it to use the first
> vdef.
>
>  /* Note that for propagation purposes, we are only interested in
>  visiting statements that load the exact same memory reference
>  stored here.  Those statements will have the exact same list
>  of virtual uses, so it is enough to set the output of this
>  statement to be its first virtual definition.  */
>
>
> You are changing this, AFAIK, so you will need to make it handle
> multiple output values.
>

That's indeed the problem:

Consider the following stmt that is been visited -

# MPT.1416_722 = VDEF  { MPT.1416 }
D.61410.first = i0_62;

Than output_p will be set to MPT.1416_722 (which is the
only vdef of this stmt) -

*output_p = first_vdef (stmt);

And later on (in add_ssa_edge () function) all the uses of MPT.1416_722
will be added to the working set which in our case is D.61410.second =
97; statement instead of the real uses of D.61410.first.

# MPT.1416_723 = VDEF  { MPT.1416 }
D.61410.second = 97;

Is there a way to retrieve the real uses of D.61410.first?

Thanks again,
Revital

Creating new variable in tree level

[Revital1 Eres]

Hello,

I appreciate your help in figuring what is considered a valid sequence
of operations for creating a new variable in the tree level.

Is the following sequence OK -

 tmp_var = create_tmp_var (type, "_new_");
 add_referenced_tmp_var (tmp_var);
 mark_sym_for_renaming (tmp_var);

Or should I also use ssa functions as follows:

temp = create_tmp_var (TREE_TYPE (expr), "pretmp");
add_referenced_tmp_var (temp);
newexpr = build (MODIFY_EXPR, TREE_TYPE (expr), temp, newexpr);
name = make_ssa_name (temp, newexpr);
TREE_OPERAND (newexpr, 0) = name;
tsi_link_after (&tsi, newexpr, TSI_CONTINUE_LINKING);

Also, I do not understand what is the usage of each function
in creating the new variable.

Thanks,
Revital

Generating a phi node

[Revital1 Eres]

Hello,

I have two ssa vars (i0 and i1 in the following example); what is the
sequence to generate a new phi node corresponding to i3 -

if (...)
 i0 = exp1

else
 i1 = exp2

i3 = PHI(i0 , i1);

Thanks,
Revital

Re: Help in understanding ccp propagator

[Revital1 Eres]

Hello,

I have one more question regarding the comment in
tree-ssa-ccp.c file -


  /* Note that for propagation purposes, we are only interested in
 visiting statements that load the exact same memory reference
 stored here.  Those statements will have the exact same list
 of virtual uses, so it is enough to set the output of this
 statement to be its first virtual definition.  */
  *output_p = first_vdef (stmt);

I wonder if this comment is true also if the vuses are not immediate as
in stmt no. 1 in the following example:

 1) arr[i].x = tmp1;
 ...
 2) arr[i].y = tmp2;
 ...
 3) reg1 = arr[i].x;
 ...
 4) arr[i].z = tmp2;
 ...
 5) reg2 = arr[i].x;

Is it because we are looking for the exact same memory reference (although
not immediate) it is enough to look at only first_vdef of every store we
encounter in our walk through the virtual def-use chain; or by looking
only at the first vdef we could miss vuses that could have been reached
by vdefs other than the first one?

Thanks again,
Revital

cp_compat_x_tst.o-cp_compat_y_tst.o testcase

[Revital1 Eres]

Hello,

While testing a patch on current trunk (r 125640) I've noticed that g++'s
cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
on x86_64 with the vanilla version but passes OK with the patched version
(-O2).  On ppc64 and i486 the test passes both with the vanilla and the
patched version.

 -FAIL: tmpdir-g++.dg-struct-layout-1/t026
cp_compat_x_tst.o-cp_compat_y_tst.o execute

I appreciate any clue regarding the reason this testcase fails (with
Segmentation fault) on current mainline on x86_64; this could help me
understand why the patch I'm working on caused it to pass.

Thanks,
Revital

Re: Gcc trees

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 21/06/2007 15:44:27:

> Hello.  i am Alberto
>
> I work with Gcc trees to modify c++ original code and dont find and i
> need documentation about trees because the web isnt enought information.
>
> Where are docs about gcc trees and macros to access it?
>

In GCC wiki you may find useful links:

http://gcc.gnu.org/wiki

(like GCC internal)

Looking at the GCC sources may also help...

Revital


> Thanks you
>
> Alberto

Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

Hello,

I get the following bootstrap comparison failure on powerpc64
for  Ada (--enable-languages=ada) with BOOT_CFLAGS='-O2'.

Revital

make[2]: Entering directory `/home/revital/mainline_ccp/build'
make[3]: Entering directory `/home/revital/mainline_ccp/build'
rm -f stage_current
make[3]: Leaving directory `/home/revital/mainline_ccp/build'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./ada/a-except.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/revital/mainline_ccp/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/revital/

Re: Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

> Which revision?  The Ada compiler bootstraps fine on i586 and x86-64 at
> revision 125912:125915M (i.e with structural alias analysis enabled).
>

revision 125915.

Thanks,
Revital

Re: Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

> >
> > Which revision?  The Ada compiler bootstraps fine on i586 and x86-64 at

> > revision 125912:125915M (i.e with structural alias analysis enabled).
>
> Note that if cc1-checksum.o differs, it likely means the issue is
unrelated to
> Ada.

I am now bootstrapping only c.  If that will pass OK I can check Ada on
an older revision if you wish.

Revital

>
> Arno

Re: Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

Eric Botcazou <[EMAIL PROTECTED]> wrote on 21/06/2007 21:10:15:

> > I am now bootstrapping only c.  If that will pass OK I can check Ada on
> > an older revision if you wish.
>
> I'm not sure that would really help in this case.  The fact that x86 and
> x86-64 are both clean with structural alias analysis would seem to show
> that there is no fundamental bad interaction between it and Ada anymore.
>
> We cannot really debug on PowerPC 64-bit so I'd suggest to disable Ada in
your
> builds for the time being (unless you have the time to investigate
yourself).
>
> Maybe the problem will arise on other platforms and we'll be able to
debug it.

OK.  BTW - the c bootstrap passed OK.

Thanks,
Revital
>
> --
> Eric Botcazou

Re: Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

Eric Botcazou <[EMAIL PROTECTED]> wrote on 23/06/2007 21:50:57:

> > I'm going to try the 64-bit variant.
>
> SPARC/Solaris 64-bit is OK, as well as IA-64/Linux according to:
>   http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01044.html
>
> Do you test PowerPC 32-bit or should I try a build on Darwin or AIX?

I tested it on powerpc64-linux with the default option
--with-cpu=default32.

Revital

> --
> Eric Botcazou

Re: Bootstrap comparison failure on powerpc64 for Ada

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 24/06/2007 01:17:34:

> > I tested it on powerpc64-linux with the default option
> > --with-cpu=default32.
>
> Ah, so this is a 32-bit compiler like on sparc64-linux?

--with-cpu=default32 means that the compiler itself and it's produced
code are 32 bits by default.

Revital

> --
> Eric Botcazou

Re: bootstrap broken on powerpc?

[Revital1 Eres]

> checking whether the GNU Fortran compiler is working... no
> configure: error: GNU Fortran is not working; please report a bug in
> http://gcc.gnu.org/bugzilla, attaching
>
/Develop/mainline-dn/build3/powerpc64-unknown-linux-gnu/libgfortran/config.log

> make[1]: *** [configure-target-libgfortran] Error 1
>
> Anyone else seeing this?

Yes, I get the same error with r126353.

Revital

>
> thanks,
> dorit
>

Re: Ongoing bootstrap failures on ppc64 since 2007-07-02

[Revital1 Eres]

> The newly built gfortran must be stomping on memory.  I've found that
> attached patch allows gfortran to still function.  Could someone who
> sees this problem try bootstrapping gfortran with the patch?

I will try it.

Revital

Re: Ongoing bootstrap failures on ppc64 since 2007-07-02

[Revital1 Eres]

> The newly built gfortran must be stomping on memory.  I've found that
> attached patch allows gfortran to still function.  Could someone who
> sees this problem try bootstrapping gfortran with the patch?

gfortran bootstrapped OK with this patch on ppc64 r126353.

Thanks,
Revital

ICE while bootstraping on ppc64.

[Revital1 Eres]

Hello,

The following ICE is received on r126521 while bootstraping on ppc64.

Revital

/home/eres/test_again/build/./gcc/xgcc -B/home/eres/test_again/build/./gcc/
-B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/bin/
-B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/eres/test_again/build/powerpc64-unknown-linux-gnu/include -isystem
/home/eres/test_again/build/powerpc64-unknown-linux-gnu/sys-include -g
-fkeep-inline-functions -m32 -fPIC -mstrict-align -O2  -O2 -g -O2  -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -mno-minimal-toc -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include
-I../../../../gcc/libgcc/../libdecnumber/dpd
-I../../../../gcc/libgcc/../libdecnumber -I../../../libdecnumber
-DHAVE_CC_TLS -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep
-DL_floatdisf -c ../../../../gcc/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc/libgcc/../gcc/libgcc2.c: In function ג__floatdisfג:
../../../../gcc/libgcc/../gcc/libgcc2.c:1530: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:785
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[5]: *** [_floatdisf.o] Error 1

[PATCH] Modulo-scheduling improvements. Patch 1 of 2. - A status update

[Revital1 Eres]

Hello,

I wanted to update the status of the first patch that
Vladimir had posted to improve modulo-schedualing.
(http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01468.html).

I tested this patch on ppc64 and currently there is one difference in
one of the fortran's testcases (forall_10.f90); this tescase fails on
vanilla version and passes with this patch.  I am currently working to
find the cause for this difference.

Thanks,
Revital


(See attached file: patch_sms_12_7.txt)
Index: ddg.c
===
--- ddg.c   (revision 126552)
+++ ddg.c   (working copy)
@@ -177,17 +177,18 @@
 {
   /* Some interloop dependencies are relaxed:
 1. Every insn is output dependent on itself; ignore such deps.
-2. Every true/flow dependence is an anti dependence in the
-opposite direction with distance 1; such register deps
-will be removed by renaming if broken --- ignore them.  */
-  if (!(t == OUTPUT_DEP && src_node == dest_node)
- && !(t == ANTI_DEP && dt == REG_DEP))
+ 2. Assuming a single use of any register, If there were a
+ single definition of every register we could have ignored the
+ antidependencies as every true/flow dependence is an anti
+ dependence in the opposite direction with distance 1; such
+ register deps will be removed by renaming if broken. But in
+ some cases we do see multiple definition, for instance in case
+ of long long registers so we don't remove them.  */
+  if (!(t == OUTPUT_DEP && src_node == dest_node))
add_backarc_to_ddg (g, e);
   else
free (e);
 }
-  else if (t == ANTI_DEP && dt == REG_DEP)
-free (e);  /* We can fix broken anti register deps using reg-moves.  */
   else
 add_edge_to_ddg (g, e);
 }
Index: modulo-sched.c
===
--- modulo-sched.c  (revision 126552)
+++ modulo-sched.c  (working copy)
@@ -160,7 +160,6 @@
 static void free_partial_schedule (partial_schedule_ptr);
 static void reset_partial_schedule (partial_schedule_ptr, int new_ii);
 void print_partial_schedule (partial_schedule_ptr, FILE *);
-static int kernel_number_of_cycles (rtx first_insn, rtx last_insn);
 static ps_insn_ptr ps_add_node_check_conflicts (partial_schedule_ptr,
ddg_node_ptr node, int cycle,
sbitmap must_precede,
@@ -366,7 +365,7 @@
 }
 
 static void
-print_node_sched_params (FILE * file, int num_nodes)
+print_node_sched_params (FILE *file, int num_nodes, ddg_ptr g)
 {
   int i;
 
@@ -378,7 +377,8 @@
   rtx reg_move = nsp->first_reg_move;
   int j;
 
-  fprintf (file, "Node %d:\n", i);
+  fprintf (dump_file, "Node = %d; INSN = %d\n", i,
+  (INSN_UID (g->nodes[i].insn)));
   fprintf (file, " asap = %d:\n", nsp->asap);
   fprintf (file, " time = %d:\n", nsp->time);
   fprintf (file, " nreg_moves = %d:\n", nsp->nreg_moves);
@@ -391,40 +391,7 @@
 }
 }
 
-/* Calculate an upper bound for II.  SMS should not schedule the loop if it
-   requires more cycles than this bound.  Currently set to the sum of the
-   longest latency edge for each node.  Reset based on experiments.  */
-static int
-calculate_maxii (ddg_ptr g)
-{
-  int i;
-  int maxii = 0;
 
-  for (i = 0; i < g->num_nodes; i++)
-{
-  ddg_node_ptr u = &g->nodes[i];
-  ddg_edge_ptr e;
-  int max_edge_latency = 0;
-
-  for (e = u->out; e; e = e->next_out)
-   max_edge_latency = MAX (max_edge_latency, e->latency);
-
-  maxii += max_edge_latency;
-}
-  return maxii;
-}
-
-/*
-   Breaking intra-loop register anti-dependences:
-   Each intra-loop register anti-dependence implies a cross-iteration true
-   dependence of distance 1. Therefore, we can remove such false dependencies
-   and figure out if the partial schedule broke them by checking if (for a
-   true-dependence of distance 1): SCHED_TIME (def) < SCHED_TIME (use) and
-   if so generate a register move.   The number of such moves is equal to:
-  SCHED_TIME (use) - SCHED_TIME (def)   { 0 broken
-   nreg_moves = --- + 1 - {   dependence.
-ii  { 1 if not.
-*/
 static struct undo_replace_buff_elem *
 generate_reg_moves (partial_schedule_ptr ps, bool rescan)
 {
@@ -534,40 +501,8 @@
   return reg_move_replaces;
 }
 
-/* We call this when we want to undo the SMS schedule for a given loop.
-   One of the things that we do is to delete the register moves generated
-   for the sake of SMS; this function deletes the register move instructions
-   recorded in the undo buffer.  */
-static void
-undo_generate_reg_moves (partial_schedule_ptr ps,
-struct undo_replace_buff_elem *reg_move_replaces)
-{
-  int i,j;
 
-  for (i = 0; i < ps->g->num_nodes; i++)
-

Summary of the BOF regarding the general policy of floating point arithmetic in GCC

[Revital1 Eres]

Hello,

The summary of the BOF regarding floating point arithmetic in GCC from
the summit can be found in the following wiki page:

http://gcc.gnu.org/wiki/FP_BOF

Thanks,
Revital

Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin

[Revital1 Eres]

Also on ppc64.

Revital

[EMAIL PROTECTED] wrote on 17/08/2007 09:55:38:

>
> I want to flag that some changes in GCC 4.3.0 20070816 rev 127568:
>
> * Makefile.in (REVISION): New.
> (REVISION_c): New.
> (REVISION_s): New.
> (version.o): Also depend on $(REVISION). Add
> -DREVISION=$(REVISION_s).
>
> * version.c (version_string): Add REVISION.
>
> causes failure on Cygwin:
>
>
> gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/tmp/gcc/gcc
> -I/tmp/gcc/gcc/. -I/tmp/gcc/gcc/../include
> -I/tmp/gcc/gcc/../libcpp/include  -I/tmp/gcc/gcc/../libdecnumber
> -I/tmp/gcc/gcc/../libdecnumber/bid -I../libdecnumber
> /tmp/gcc/gcc/varray.c -o varray.o
> gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/tmp/gcc/gcc
> -I/tmp/gcc/gcc/. -I/tmp/gcc/gcc/../include
> -I/tmp/gcc/gcc/../libcpp/include  -I/tmp/gcc/gcc/../libdecnumber
> -I/tmp/gcc/gcc/../libdecnumber/bid -I../libdecnumber
/tmp/gcc/gcc/vec.c
> -o vec.o
> make[3]: *** No rule to make target /tmp/gcc/gcc/REVISION', needed by
> version.o'.  Stop.
> make[3]: Leaving directory /tmp/gcc/build/gcc'
> make[2]: *** [all-stage1-gcc] Error 2
> make[2]: Leaving directory /tmp/gcc/build'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory /tmp/gcc/build'
> make: *** [all] Error 2
>
>
> Cheers,
>
>   Angelo.

Re: gcc.dg/sms-antideps.c fails on IA64 (modulo scheduling problem)

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 18/08/2007 03:19:48:

> I noticed that gcc.dg/sms-antideps.c is failing on my IA64 Linux and
> HP-UX platforms.  The failure is:
>
> x.c: In function 'foo':
> x.c:25: internal compiler error: in gen_sub2_insn, at optabs.c:4640
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
>
> When I enter gen_sub2_insn the operands I have are:
>
>(reg:DI 332 ar.lc) and (const_int 0 [0x0])
>

Andrey already brought that problem to our attention; please see -
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01010.html; It will be
addressed in the next patch.

Thank,
Revital

Build failure on ppc64

[Revital1 Eres]

Hello,

I get the following error on ppc64 with trunk r127835:

c/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/regclass.c -o regclass.o
../../gcc/gcc/regclass.c: In function גinit_reg_autoincג:
../../gcc/gcc/regclass.c:1224: error: גforbidden_inc_dec_classesג
undeclared (first use in this function)
../../gcc/gcc/regclass.c:1224: error: (Each undeclared identifier is
reported only once
../../gcc/gcc/regclass.c:1224: error: for each function it appears in.)

Thanks,
Revital

ICE in langhooks.c on SPU

[Revital1 Eres]

Hello,

I get the following ICE with trunk r127857 running the testsuite on SPU:

:0: internal compiler error: in add_builtin_function, at
langhooks.c:485^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M
compiler exited with status 1
output is:
:0: internal compiler error: in add_builtin_function, at
langhooks.c:485^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

Thanks,
Revital

Re: ICE in langhooks.c on SPU

[Revital1 Eres]

> Wow, you mean SPU has more builtins than x86_64?  Up the bitfield
> width of tree.h tree_function_decl.function_code until it no longer ICEs.
>

Changing the following indeed solves the problem:

Index: tree.h
===
--- tree.h  (revision 127857)
+++ tree.h  (working copy)
@@ -3312,7 +3312,7 @@
  DECL_FUNCTION_CODE.  Otherwise unused.
  ???  The bitfield needs to be able to hold all target function
  codes as well.  */
-  ENUM_BITFIELD(built_in_function) function_code : 10;
+  ENUM_BITFIELD(built_in_function) function_code : 11;
   ENUM_BITFIELD(built_in_class) built_in_class : 2;

   unsigned static_ctor_flag : 1;

Thanks,
Revital


> A patch that fixes this this way is pre-approved.
>
> Thanks,
> Richard.

Re: ICE in langhooks.c on SPU

[Revital1 Eres]

[EMAIL PROTECTED] wrote on 28/08/2007 17:31:08:

> On 8/28/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > On 28 August 2007 15:10, Richard Guenther wrote:
> >
> > >
> > > Or maybe on ppc/spu enum bitfields are signed and the following
> > >
> > >   DECL_FUNCTION_CODE (decl)  = -1;
> > >   gcc_assert (DECL_FUNCTION_CODE (decl) >= function_code);
> > >
> > > doesnt work?
> >
> >   I saw what you did there, and thought it slightly peculiar.  Wouldn't
> >
> > DECL_FUNCTION_CODE (decl) = function_code;
> > gcc_assert (DECL_FUNCTION_CODE (decl) == function_code);
> >
> > have worked just as well, or is there some gotcha you were trying to
avoid with
> > the dead store trick?
>
> Oh, indeed - this looks like it should have less problems.  Revital, if
that
> works for you then changing the code above to what Dave suggests is also
> pre-approved (but it really might be that SPU needs more than 1024
builtin
> functions of a kind).

It seems that replacing the above code does not solve the problem.

Thanks,
Revital

Error in c-lex.c

[Revital1 Eres]

Hello,

I get the following error running trunk r127993 with
--enable-checking=assert on ppc64:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc/gcc/c-lex.c -o c-lex.o
../../gcc/gcc/c-lex.c: In function גinterpret_floatג:
../../gcc/gcc/c-lex.c:645: error: גCPP_N_FRACTג undeclared (first use in
this function)
../../gcc/gcc/c-lex.c:645: error: (Each undeclared identifier is reported
only once
../../gcc/gcc/c-lex.c:645: error: for each function it appears in.)
../../gcc/gcc/c-lex.c:645: error: גCPP_N_ACCUMג undeclared (first use in
this function)
../../gcc/gcc/c-lex.c: In function גinterpret_fixedג:
../../gcc/gcc/c-lex.c:753: error: גCPP_N_FRACTג undeclared (first use in
this function)
make[3]: *** [c-lex.o] Error 1

Thanks,
Revital