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 [0
[EMAIL PROTECTED] wrote on 02/06/2005 04:29:17:
> Steven Bosscher <[EMAIL PROTECTED]>:
>
> > On Wednesday 01 June 2005 16:43, Canqun Yang wrote:
> > > Hi, all
> > >
> > > I've taken a look on modulo-sched.c recently, and found
> > > that both new_cycles and orig_cycles are imprecise. The
> > >
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 coun
am asking again 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
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
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 gu
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)
_FPTR(my_foo_record->ppaddr)(n))) {
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 fil
Steven Bosscher <[EMAIL PROTECTED]> wrote on 22/04/2005 09:39:09:
>
> Thanks!
> For the record, this refers to a patch I sent to Mostafa and Canqun to
> do what Mostafa suggested last month to make SMS work for ia64, see
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02848.html.
I have teste
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
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 for
Steven Bosscher <[EMAIL PROTECTED]> wrote on 31/03/2005 16:55:52:
> On Mar 31, 2005 03:56 PM, Canqun Yang <[EMAIL PROTECTED]> wrote:
>
> > This patch will fix doloop_register_get defined in
> > modulo-sched.c, and let the program of PI caculation
> > on IA-64 be successfully modulo scheduled.
Hi Mark,
First of all I would like this discussion to be on the GCC mailing list; so
I am CCing the GCC mailing list (I hope this is OK with all the others).
"Davis, Mark" <[EMAIL PROTECTED]> wrote on 31/03/2005 00:23:02:
> Mostafa & Gerald,
>
...
> It was mentioned that you folks had recentl
"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 ca
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
machin
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 ../../../gcc/libiber
James E Wilson <[EMAIL PROTECTED]> wrote on 18/03/2005 07:43:55:
>
> You either have to keep all REG_NOTES up to date, or call code that will
> recompute them. You can recompute REG_DEAD/REG_UNUSED notes by calling
> back into flow. This is presumably what happens when you mark the block
>
maybe 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:
> Follo
[EMAIL PROTECTED] (Richard Kenner) wrote on 16/03/2005 17:27:59:
> REG_NOTE (NONNEG)
> REG_NOTE (NO_CONFLICT)
> REG_NOTE (UNUSED)
>mustn't be copied
>describe a fact about other instructions so this
>may change if copied.
>
> Tricky. Often UNUSED means that
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 n
> * Project Title
SMS (Modulo Scheduling) Improvements.
>
> * Project Contributors
Mostafa Hagog
>
> * Dependencies
No dependencies.
>
> * Delivery Date
Ready, currently committed to the autovect-branch.
>
> * Description
>
> Describe the project *i
Where should I add a description for SMS in changes.html?
I see that only the tree-ssa optimizations are described (as general
new optimizations), is this the intention?
Please discard the previous message it was send by mistake.
[EMAIL PROTECTED] wrote on 12/02/2005 20:34:57:
>
>
>
>
> > * Project Title
> I. SMS (Modulo Scheduling) Improvements.
>
> >
> > * Project Contributors
> Mostafa Hagog
>
> >
> >
> * Project Title
I. SMS (Modulo Scheduling) Improvements.
>
> * Project Contributors
Mostafa Hagog
>
> * Dependencies
No dependencies.
>
> * Delivery Date
Ready, currenly committed to the autovect-branch.
>
> * Description
>
> Describe the project *i
24 matches
Mail list logo
