Hi,
Steven Bosscher [EMAIL PROTECTED] wrote on 30/06/2005 01:46:22:
Hi,
[snip]
Then the ia64 machine-reorg scheduler gets to work, and it produces:
(insn:TI 8 70 12 0 (set (reg:BI 262 p6 [353])
(ne:BI (reg/v:SI 15 r15 [orig:348 b1 ] [348])
(const_int 0 [0x0])))
Steven Bosscher [EMAIL PROTECTED] wrote on 01/06/2005 17:35:20:
On Wednesday 01 June 2005 16:43, Canqun Yang wrote:
3) The counted loop register 'ar.lc' of IA-64 can not be
updated directly. Another temporary register is needed
to evaluate the value of the actural loop count after
for approval to
commit.
2005-05-23 Mostafa Hagog [EMAIL PROTECTED]
* gcse.c (compute_transp, load_killed_in_block): use MEM_READONLY_P.
(See attached file: gcse_las3.patch)
gcse_las3.patch
Description: Binary data
Richard Henderson [EMAIL PROTECTED] wrote on 09/05/2005 19:35:34:
On Mon, May 09, 2005 at 05:45:24PM +0300, Mostafa Hagog wrote:
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (! MEM_READONLY_P (x))
Looks like you should push
Paolo Bonzini [EMAIL PROTECTED] wrote on 09/05/2005 18:09:10:
It appears that GCSE considers read only memory as call clobbered,
which
is not the case in CSE. I have took the test for read-only memory from
CSE
and add it to GCSE where we compute the transparency.
My wild guess is that
I want to add the below example as a regression test; the difference
between the success and failure is the position of a load operation. Is
there a possibility to check this using the scan-assembler?
Mostafa Hagog wrote on 09/05/2005 17:45:24:
It appears that GCSE considers read only
))) {
MY_FOO_CHECK();
}
return 0;
}
The patch:
2005-05-09 Mostafa Hagog [EMAIL PROTECTED]
* gcse.c (compute_transp): use MEM_READONLY_P in case of MEM.
Index: gcse.c
===
RCS file: /cvs/gcc/gcc/gcc/gcse.c,v
retrieving revision
Andrew Haley wrote on 11/04/2005 13:31:52:
Steven Bosscher writes:
This is what C++ does now too. Why would this be a problem
for Java but not for C++?
I don't know why it's not a problem for C++; I do know why it's a
problem for Java. Perhaps the files we're compiling are
There have been lately a discussion on the GCC mailing list and other
forums about the efficiency of SMS (the current implementation of software
pipelining in GCC). One of the issues that currently limit SMS is the lack
of loop carried memory dependency information. The long term solution
zhongknocken [EMAIL PROTECTED] wrote on 29/03/2005 06:29:54:
I've tried the dot-product loop and some other loops on Itanium machine.
The
machine description of the target processor has DFA defined for it. The
function sms_schedule is invoked, but no loop is SMS scheduled.
You can use
This is highly dependent on the target processor for which you are trying
to schedule the loops. For example, If the machine description of the
target processor doesn't have DFA defined for it SMS is not performed at
all. One good example of a loop that would be scheduled in SMS (on a G5
I guess its due to the following patch (
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01320.html).
I get the following error when trying to build gcc on powerpc-apple-darwin:
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W
-Wall -Wtraditional -pedantic
Following the discussion in bugzilla I have came to a conclusion that the
problem is that we copy REG_NOTEs along with the instructions. they belong
to. This is not correct for some kinds of REG_NOTE. The fix is to prevent
us from copying the notes in some of the cases. I have went over the
it is still
correct to keep their.
The question is: what is the correct fix for the longer term ?
is it enough to mark the SMSed block dirty? or do we need
also to keep the REG_DEAD correct in each basic-block
separately?
Mostafa Hagog/Haifa/IBM wrote on 16/03/2005 17:17:35:
Following
14 matches
Mail list logo
