Re: query regarding adding a pass to undo final value replacement.
Hi,
> > but you only take the hash of the argument of the phi node (i.e., the
> > ssa name), not the computations on that it is based
>
> Is this something like what you had in mind ?
>
> gen_hash (stmt)
> {
>
> if (stmt == NULL)
> return 0;
>
> use_operand_p use_p;
> ssa_op_iter iter;
> val += get_changed_stmt_hash (stmt);
> FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
> {
> tree use = USE_FROM_PTR (use_p);
> val += get_stmt_hash (use);
> val += gen_hash (SSA_NAME_DEF_STMT (use));
> }
> }
> else
> val += generate_phi_node_hashcode (stmt);
>
>
> return val;
> }
>
> and one calls this in continuation to my earlier email by
>
>
>arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
>op0 = USE_FROM_PTR (arg_p);
>val = iterative_hash_expr (op0, val);
>if (TREE_CODE (op0) == SSA_NAME)
> {
>val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
>val += SSA_NAME_VERSION (op0);
>
>val += gen_hash (SSA_NAME_DEF_STMT (op0));
otoh, there seem to be at least four problems with this:
1) The fact that the statement is identical does not mean that
it also returns the same value (calls, memory accesses, ...).
I guess one could argue that if FVR succeeded, we should not
run into such problems, which is a bit shaky reasoning, but
might actually be the case.
2) You would be hashing everything reachable through the uses,
which as written will lead to an infinite loop in any program
with a cycle. Even if this were fixed, hashing (potentially)
whole program would be extremely slow.
3) Two different expressions may have the same hash value.
4) SSA_NAME_DEF_STMT (op0) may have been removed, so this would
be accessing garbage.
Zdenek
Re: query regarding adding a pass to undo final value replacement.
On Wed, Oct 15, 2008 at 8:37 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> > but you only take the hash of the argument of the phi node (i.e., the
>> > ssa name), not the computations on that it is based
>>
>> Is this something like what you had in mind ?
>>
>> gen_hash (stmt)
>> {
>>
>> if (stmt == NULL)
>> return 0;
>>
>> use_operand_p use_p;
>> ssa_op_iter iter;
>> val += get_changed_stmt_hash (stmt);
>> FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
>> {
>> tree use = USE_FROM_PTR (use_p);
>> val += get_stmt_hash (use);
>> val += gen_hash (SSA_NAME_DEF_STMT (use));
>> }
>> }
>> else
>> val += generate_phi_node_hashcode (stmt);
>>
>>
>> return val;
>> }
>>
>> and one calls this in continuation to my earlier email by
>>
>>
>>arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
>>op0 = USE_FROM_PTR (arg_p);
>>val = iterative_hash_expr (op0, val);
>>if (TREE_CODE (op0) == SSA_NAME)
>> {
>>val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
>>val += SSA_NAME_VERSION (op0);
>>
>>val += gen_hash (SSA_NAME_DEF_STMT (op0));
>
> otoh, there seem to be at least four problems with this:
>
> 1) The fact that the statement is identical does not mean that
> it also returns the same value (calls, memory accesses, ...).
> I guess one could argue that if FVR succeeded, we should not
> run into such problems, which is a bit shaky reasoning, but
> might actually be the case.
> 2) You would be hashing everything reachable through the uses,
> which as written will lead to an infinite loop in any program
> with a cycle. Even if this were fixed, hashing (potentially)
> whole program would be extremely slow.
> 3) Two different expressions may have the same hash value.
> 4) SSA_NAME_DEF_STMT (op0) may have been removed, so this would
> be accessing garbage.
I've already hit 2 whilst building with the patch and I agree that
hashing through the uses is going to make compilation very slow. I
don't see an easy option then to add the checks for hashing the SSA
names . Is there something else that I could try ?
cheers
Ramana
>
> Zdenek
>
--
Ramana Radhakrishnan
How to debug if scheduling in gcc is wrong?
Hi, I'm a guy working with gcc4.1.1 on itanium2. In my work, some instrumentations are added by gcc. After instrumentation, all specint2000 benchmarks except gzip can successfully run with optimization flag -O3. There are some information list below: 1. Gzip can successfully run when compile with -O1(-O2 and -O3 failed). 2. When add code "while(1)" in an unreachable place in function "huft_build", gzip can successfully run. 3. Our instrumentation add two new instruction supports to gcc, which are tnat and single predicate compare: Machine description file === (define_insn "shift_predicate_cmp" [(set (match_operand:BI 0 "register_operand" "=c") (and:BI (and:BI (const_int 1) (ne:BI (match_operand:DI 1 "gr_reg_or_8bit_adjusted_operand" "rL") (match_operand:DI 2 "gr_register_operand" "r"))) (const_int 1)))] "" "cmp.ne %0, p0 = %1, %2" [(set_attr "itanium_class" "icmp")]) (define_insn "shift_tnat" [(set (match_operand:BI 0 "register_operand" "=c") (unspec:BI [(match_operand:DI 1 "gr_register_operand" "r")] UNSPEC_TNAT))] "" "tnat.nz %0, p0 = %1" [(set_attr "itanium_class" "tbit")]) 4. Impossible to compare compiled .s files(the one with "while(1)" vs. the one without) since instruction scheduling make it completely different. My question are: 1. Whether this implementation could possibly make gcc's scheduling go wrong? 2. Is there any good way to debug such problems? Any help are appreciated, thanks very much.
Re: A question about DCE
Revital1 Eres wrote: 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) You really need to show that the register is used somewhere -- mixing implicit and explicit uses (and defs) of objects is ultimately going to lead to problems. Pick one (I usually recommend explicit) and stick to it. From what little information you've given, I'd say explicit uses/defs is the way to go. jeff
Re: A question about DCE
On Wed, Oct 15, 2008 at 11:17:18AM +0200, Revital1 Eres wrote: > > 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. 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)? -- Daniel Jacobowitz CodeSourcery
A question about DCE
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
Revital, * Revital1 Eres <[EMAIL PROTECTED]> [2008-10-15 02:20]: > > 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). You are using r77 as a function argument for this other routine. I believe there is a way to tell GCC that this function uses a special ABI, that it uses different parameter registers. Trevor
Feature request: issue a warning when function declaration looks like variable definition
The following problem is very common when dealing with iterators,
function objects and/or algorithms in C++. This is a simple test case:
#include
#include
#include
int main() {
using namespace std;
typedef istreambuf_iterator isbi;
string str(isbi(cin), isbi()); // Line 8
cout << str << endl; // Line 9
}
The code above, even though it looks correct to experienced C++
programmer and compiles fine, does definitely not do what the programmer
intended it to.
The program was meant to read all characters from std::cin, until EOF,
into str. Instead, it reads nothing from there and just prints value 1
to std::cout, as also suggested this warning message (enabled by -Wall):
test.cpp:9: warning: the address of ‘std::string str(main()::isbi,
main()::isbi (*)())’ will always evaluate as ‘true’
This message may tell an experienced C++ programmer what the actual
problem is, but even then it points at the wrong line. Depending on how
str is used, there might be even more obscure errors, especially if str
is passed to a template function.
The problem here is that the C++ standard requires line 8 to be
interpreted as a declaration of a function named str, returning string
and taking two arguments of type isbi (the first one is named cin and
the second one is anonymous). The extra parenthesis around variable
names are ignored.
However, since it is not conventional to use parenthesis around variable
names in function declarations, this problem could be analyzed by GCC,
issuing a proper warning.
My suggestion:
Whenever a function declaration with parenthesis around parameter names
is seen, issue a warning:
:: warning: '' is interpreted as a function
declaration, but it looks like a variable definition (put parenthesis
around '' to make it so)
E.g. in the above case:
test.cc:8: warning: 'str' is interpreted as a function declaration, but
it looks like a variable definition (put parenthesis around 'isbi(cin)'
to make it so)
Note: the case of variable initialization without arguments (also
interpreted as a function declaration) cannot be diagnosed in this
manner. Therefore no warning should be issued on this: string str();
People generally learn to write just string str; rather quickly.
Re: A question about DCE
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
Feature request: issue a warning when function declaration looks like variable definition
The following problem is very common when dealing with iterators,
function objects and/or algorithms in C++. This is a simple test case:
#include
#include
#include
int main() {
using namespace std;
typedef istreambuf_iterator isbi;
string str(isbi(cin), isbi()); // Line 8
cout << str << endl; // Line 9
}
The code above, even though it looks correct to experienced C++
programmer and compiles fine, does definitely not do what the programmer
intended it to.
The program was meant to read all characters from std::cin, until EOF,
into str. Instead, it reads nothing from there and just prints value 1
to std::cout, as also suggested this warning message (enabled by -Wall):
test.cpp:9: warning: the address of ‘std::string str(main()::isbi,
main()::isbi (*)())’ will always evaluate as ‘true’
This message may tell an experienced C++ programmer what the actual
problem is, but even then it points at the wrong line. Depending on how
str is used, there might be even more obscure errors, especially if str
is passed to a template function.
The problem here is that the C++ standard requires line 8 to be
interpreted as a declaration of a function named str, returning string
and taking two arguments of type isbi (the first one is named cin and
the second one is anonymous). The extra parenthesis around variable
names are ignored.
However, since it is not conventional to use parenthesis around variable
names in function declarations, this problem could be analyzed by GCC,
issuing a proper warning.
My suggestion:
Whenever a function declaration with parenthesis around parameter names
is seen, issue a warning:
:: warning: '' is interpreted as a function
declaration, but it looks like a variable definition (put parenthesis
around '' to make it so)
E.g. in the above case:
test.cc:8: warning: 'str' is interpreted as a function declaration, but
it looks like a variable definition (put parenthesis around 'isbi(cin)'
to make it so)
Note: the case of variable initialization without arguments (also
interpreted as a function declaration) cannot be diagnosed in this
manner. Therefore no warning should be issued on this: string str();
People generally learn to write just string str; rather quickly.
Fwd: We provide a web page with binaries of binutils/gcc/gdb you might want add to http://gcc.gnu.org/install/binaries.html
Date: Wed, 15 Oct 2008 15:15:45 -0400 To: [EMAIL PROTECTED] From: James MacGregor <[EMAIL PROTECTED]> Subject: We provide a web page with binaries of binutils/gcc/gdb you might want add to http://gcc.gnu.org/install/binaries.html Cc: "Craig Haller" <[EMAIL PROTECTED]> Gentlemen: Macraigor Systems builds and makes available for free the binaries of gcc 4.3.2, gcc 6.6, and binutils 2.18 built for arm-elf, m68k-elf, mips-elf, powerpc-elf, i386-elf targets. We provide : InstallShields for cywin hosts under Windows/Vista and rpm files for linux hosts. from the web page : http://www.macraigor.com/full_gnu.htm Downloading/installing our OcdRemote package for this web site installs example Eclipse/GNU tools projects (including source, makefile, ldscript, readme, and gdbinit for downloading and running the example on a target board using Macraigor JTAG devices) for many different CPU manufacturer's evaluation boards. Users of gcc may find this web page useful. You may want to provide a link to it. James MacGregor Managing Partner Macraigor Systems LLC 227 Cypress Street Brookline MA 02445 617 739 8693 James MacGregor Managing Partner Macraigor Systems LLC 227 Cypress Street Brookline MA 02445 617 739 8693
Re: Feature request: issue a warning when function declaration looks like variable definition
On Wed, Oct 15, 2008 at 09:54:36PM +0300, Lasse Kärkkäinen wrote:
> The following problem is very common when dealing with iterators,
> function objects and/or algorithms in C++.
Yes, I ran into this issue myself earlier this week. It's a more
general problem, striking whenever the arguments to a constructor
are themselves constructor calls.
> This is a simple test case:
>
> #include
> #include
> #include
>
> int main() {
> using namespace std;
> typedef istreambuf_iterator isbi;
> string str(isbi(cin), isbi()); // Line 8
> cout << str << endl; // Line 9
> }
> ...
> The problem here is that the C++ standard requires line 8 to be
> interpreted as a declaration of a function named str, returning string
> and taking two arguments of type isbi (the first one is named cin and
> the second one is anonymous). The extra parenthesis around variable
> names are ignored.
>
> However, since it is not conventional to use parenthesis around variable
> names in function declarations, this problem could be analyzed by GCC,
> issuing a proper warning.
Good idea.
> My suggestion:
>
> Whenever a function declaration with parenthesis around parameter names
> is seen, issue a warning:
>
> :: warning: '' is interpreted as a function
> declaration, but it looks like a variable definition (put parenthesis
> around '' to make it so)
But the wording of the warning needs work, as "make it so" is ambiguous here.
Perhaps
:: warning: '' is interpreted as a function
declaration; put parentheses around the first argument to make it
a variable definition
Another way to get the correct interpretation is to write
string str = string(isbi(cin), isbi());
> Note: the case of variable initialization without arguments (also
> interpreted as a function declaration) cannot be diagnosed in this
> manner. Therefore no warning should be issued on this: string str();
> People generally learn to write just string str; rather quickly.
string str();
looks like a function declaration, so users are less likely to write
this when declaring a string.
error: unable to emulate 'DI'
Hi All, I have a similar issue to what is reported here (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143): /Applications/avr/avr-src/gcc/unwind.h:59: error: unable to emulate 'DI' As you clearly expressed by Paul, the underline issue that the target only support data types up to 32-bits, while gcc is expecting up to 64-bit support. Any suggestions on how to workaround this? Thanks, -Omar
gcc-4.2-20081015 is now available
Snapshot gcc-4.2-20081015 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081015/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 141151 You'll find: gcc-4.2-20081015.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20081015.tar.bz2 C front end and core compiler gcc-ada-4.2-20081015.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20081015.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20081015.tar.bz2 C++ front end and runtime gcc-java-4.2-20081015.tar.bz2 Java front end and runtime gcc-objc-4.2-20081015.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20081015.tar.bz2The GCC testsuite Diffs from 4.2-20081008 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Rewrite of tree level PRE and vect-67.c failure
Dan and Richard, Are either of you aware of the gcc.dg/vect/vect-67.c failure that is occuring on some platforms? I see it on IA64 (Linux and HP-UX) but a scan of the gcc-testresults mailing lists shows failures on x86_64 and powerpc as well. Looking into the failure, I see that it started (at least on IA64) at version r137631, which is the checkin for the tree level PRE rewrite that was done back in July. That checkin mentions some known pre-* test regressions that would happen for a while but I didn't see any mention of vect-67.c. Steve Ellcey [EMAIL PROTECTED]
STRIP NOPS Question
Hello Everyone, In GCC I found a MACRO called STRIP_NOPS and it is defined as the following: #define STRIP_NOPS(EXP) \ while ((TREE_CODE (EXP) == NOP_EXPR \ || TREE_CODE (EXP) == CONVERT_EXPR\ || TREE_CODE (EXP) == NON_LVALUE_EXPR)\ && TREE_OPERAND (EXP, 0) != error_mark_node\ && (TYPE_MODE (TREE_TYPE (EXP))\ == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0) \ (EXP) = TREE_OPERAND (EXP, 0) I am currently having a VLIW architecture and I want to put NOPs between the dependent instructions... So if I disable this #define, then will it do the trick? Can someone please explain to me ohw this works? Any help is greatly appreciated! Please CC me in your response since I am not a subscribed to this list. Yours Sincerely, 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.
Re: STRIP NOPS Question
On Thu, Oct 16, 2008 at 7:12 AM, Balaji V. Iyer <[EMAIL PROTECTED]> wrote: > Hello Everyone, >In GCC I found a MACRO called STRIP_NOPS and it is defined as the > following: > > #define STRIP_NOPS(EXP) \ > while ((TREE_CODE (EXP) == NOP_EXPR \ > || TREE_CODE (EXP) == CONVERT_EXPR\ > || TREE_CODE (EXP) == NON_LVALUE_EXPR)\ > && TREE_OPERAND (EXP, 0) != error_mark_node\ > && (TYPE_MODE (TREE_TYPE (EXP))\ > == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0) \ >(EXP) = TREE_OPERAND (EXP, 0) > You are confusing macros at different times in the compiler . STRIP_NOPS happens at the tree level whilst scheduling happens on RTL . This isn't the same as the nops you want to introduce for your pipeline hazards. > > I am currently having a VLIW architecture and I want to put NOPs between > the dependent instructions... So if I disable this #define, then will it > do the trick? Can someone please explain to me ohw this works? You need to define your pipeline automaton and then insert nops to avoid data hazards using machine_reorg or a trick as described by Ian here. http://gcc.gnu.org/ml/gcc/2006-03/msg00627.html cheers Ramana > > Any help is greatly appreciated! > > Please CC me in your response since I am not a subscribed to this list. > > Yours Sincerely, > > 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. > > > -- Ramana Radhakrishnan
