Doubt about scheduling
Hello all, I got few doubts regarding the way in which scheduling works in gcc 4.1.2 1. Will barrier insns gets scheduled along with other instructions? 2. When there is an unconditional jump in the instruction list, a barrier instruction gets emitted after the unconditional jump as the last instruction. Will this be regarded as an instruction when counting the number of instructions in a region for scheduling purposes? 3. After the end of scheduling a region can barrier remain as the last instruction in the ready list unscheduled? Or in other words can ready list be 'non-empty' after scheduling a region? Regards, Shafi
Re: more m32c brokenness
On Wed, Apr 9, 2008 at 10:40 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > I tracked it down to this: > > > /* Allow conversions between integral types and pointers only if >there is no sign or zero extension involved. */ > if (((POINTER_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (op))) > || (POINTER_TYPE_P (TREE_TYPE (op)) && INTEGRAL_TYPE_P (type))) > && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (op))) > return false; > > The code does not do what the comment says. It also requires that > there be no truncation. > > However, of course, other parts of the compiler complain about > truncation as well. > > The root cause is this: > > ptr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (ptr), ptr, > fold_convert (sizetype, vtable)); > > We fold_convert to sizetype, without regard for whether it's the same > precision as TREE_TYPE (ptr). vtable is the right size, ptr is the > right size, but we're creating an intermediate that's the wrong size. > > Can we put in a calculate-unsigned-for-type call here? That should be > sizetype for everyone else, but the special type for m32c. This particular case indeed needs fixing (I assume vtable is a pointer). There is build_nonstandard_integer_type for this. Richard.
Mapping back to original variables after SSA optimizations
Hi all, i have a doubt about unSSA: is it allways possible to map back the versioned variables to the original variable? If it could be possible, is there an algorithm that describe this translation back? I have read the paper "Efficiently computing static single assignment form and the control dependence graph (cytron91)" and no way to translate back from SSA is explained, it only points out that after SSA optimizations "dead code elminitation" and "allocation by colloring" are recommended to be performed. Thanks Fran
Re: Fusing two loops
Hi,
The error is rectified. The bug is in the function that calls fuse_loops().
Now I am trying to transfer all the statements, using code -
/* The following function fuses two loops. */
void
fuse_loops (struct loop *loop_a, struct loop *loop_b)
{
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
block_stmt_iterator bsi_a = bsi_start (loop_a->header);
block_stmt_iterator bsi_a_last = bsi_last (loop_a->header);
block_stmt_iterator bsi_b = bsi_last (loop_b->header);
while (&bsi_a != &bsi_a_last)
{
bsi_move_before (&bsi_a, &bsi_b);
fprintf (stderr, " transferred one statement from loop %d to
loop %d ", loop_a->num, loop_b->num);
bsi_next (&bsi_a);
}
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
cancel_loop_tree (loop_a);
}
After doing this I get a segmentation fault , after 3 statements of
loop_a are transferred to loop_b.
Program received signal SIGSEGV, Segmentation fault.
0x08436245 in tsi_next (i=0xb5b0) at ../../trunk/gcc/tree-iterator.h:74
74i->ptr = i->ptr->next;
Thanks,
Sandeep.
On Thu, Apr 10, 2008 at 5:57 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> > I have written this function
> >
> > /* The following function fuses two loops. */
> >
> > void
> > fuse_loops (struct loop *loop_a, struct loop *loop_b)
> > {
> > debug_loop (loop_a, 10);
> > debug_loop (loop_b, 10);
> > block_stmt_iterator bsi_a = bsi_start (loop_a->header);
> > block_stmt_iterator bsi_b = bsi_last (loop_b->header);
> > bsi_move_before (&bsi_a, &bsi_b);
> > fprintf (stderr, " transferred one statement from loop %d to loop %d
> > ", loop_a->num, loop_b->num);
> > debug_loop (loop_a, 10);
> > debug_loop (loop_b, 10);
> > cancel_loop_tree (loop_a);
> > }
> >
> > It moved one statement from loop_a to loop_b. In the same way I must
> > tranfer all other statements too. I get a internal compiler error at "
> > cancel_loop_tree(loop_a); "
>
> where exactly (can you send me a backtrace)? It does not seem possible
> for cancel_loop_tree to ICE, if fuse_loops is the only function that you
> call.
>
> Zdenek
>
I wished to write to you
Hello!!! I find your email in internet and I wished to write to you. You do not know me... and I do not know you. But I trust in destiny and I hope that destiny give me a chance I want to find a kind, honest and clever man. My name - Natalya. My age-26 years.It is difficult to tell about myself. If this is of any interest to you, write to me I hope, I can see your letter soon. In the following letter I to tell about myself and send my photos. Write on my personal email: [EMAIL PROTECTED] now I write with the work and my chief does not know about it. Sincerely, Natalya.
Re: US-CERT Vulnerability Note VU#162289
Gerald,
Here is another version of the program (same compiler version/flags).
#include
void test_signed(char *buf) {
signed int len;
len = 1<<30;
printf("buf = %p; buf+len = %p; buf+len < buf = %d %d",
buf, buf+len, buf+len < buf, (uintptr_t)buf+len < (uintptr_t)buf);
if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
printf(" BUG!");
printf("\n");
}
void test_unsigned(char *buf) {
unsigned int len;
len = 1<<30;
printf("buf = %p; buf+len = %p; buf+len < buf = %d %d",
buf, buf+len, buf+len < buf, (uintptr_t)buf+len < (uintptr_t)buf);
if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
printf(" BUG!");
printf("\n");
}
int main(void) {
test_signed(0);
test_signed((char*)0x7000);
test_signed((char*)0xf000);
test_unsigned(0);
test_unsigned((char*)0x7000);
test_unsigned((char*)0xf000);
return 0;
}
output:
buf = ; buf+len = 4000; buf+len < buf = 0 0
buf = 7000; buf+len = B000; buf+len < buf = 0 0
buf = F000; buf+len = 3000; buf+len < buf = 1 1
buf = ; buf+len = 4000; buf+len < buf = 0 0
buf = 7000; buf+len = B000; buf+len < buf = 0 0
buf = F000; buf+len = 3000; buf+len < buf = 1 1
The unsigned test was one we performed on the gcc versions. I added the
signed test, but it didn't make a difference on Visual Studio. My
understanding is that it shouldn't, because the real issue here is
pointer arithmetic and the resulting type should always be a pointer.
rCs
Robert C. Seacord wrote:
void f(char *buf) {
unsigned int len = len = 0xFF00;
if (buf+len < buf) puts("true");
}
You need to be more precise. That is not the same example
that you quoted for GCC.
In fact, if you vary the criteria too much, you will find
situations where GCC already behaved that way. The test in
the following example is optimized out by old versions of
GCC (certainly my version 3.4.5 compiler does it, with no
warnings even when using -Wall):
int f(char *buf, int i)
{
i = 1<<30;
if ((int)buf + i < (int)buf)
return 0;
return 1;
}
That's quite a bit less changed than your example, which
brings unsigned-ness into the picture. [This is exactly
the problem--signed overflow and pointer overflow aren't
defined, unlike unsigned overflow.]
Given that current Microsoft compilers reportedly exhibit
this behavior, it sounds like the advisory is going to at
least need some significant rewriting. :-)
-Jerry
Re: Problem with reloading in a new backend...
Le mercredi 09 avril 2008 à 18:21 -0400, DJ Delorie a écrit :
> > Maybe I should reserve a special register for this usage (say r0).
>
> That might be the only way, yes.
Ok, I reserved r0 (BP_REGNUM) for such reloads, and I'm generating new
instructions in LEGITIMIZE_RELOAD_ADDRESS to calculate the memory
address:
if (GET_CODE (*x) == PLUS
&& GET_CODE (XEXP (*x, 0)) == REG
&& GET_CODE (XEXP (*x, 1)) == CONST_INT) {
rtx reginsn, setinsn, plusinsn;
reginsn = gen_rtx_REG(Pmode, BP_REGNUM);
setinsn = gen_rtx_SET(Pmode, reginsn, XEXP (*x, 1));
plusinsn = gen_rtx_SET(Pmode, reginsn, gen_rtx_PLUS(Pmode,
reginsn, XEXP (*x, 0)));
emit_insn_before(setinsn, insn);
emit_insn_before(plusinsn, insn);
*x = reginsn;
return 1;
}
Does this sound ok ?
Note that I needed to use emit_insn_before() in order to insert the
instructions, and emit_insn_before() needs the current 'insn', which
is not passed by LEGITIMIZE_RELOAD_ADDRESS(), so I needed to modify the
macro. Is there something I miss here ?
> Note that reload also assumes that such adds don't change the flags
> (i.e. a compare/jump pair must not have a flag-modifying add between
> them).
I think this won't happen because I emit the compare/conditional branch
insn at the same time, in beq/bne/bgt... etc define_insn() (like many
other targets).
Thanks.
--
Stelian Pop <[EMAIL PROTECTED]>
Re: Fusing two loops
Hi,
> The error is rectified. The bug is in the function that calls fuse_loops().
> Now I am trying to transfer all the statements, using code -
>
> /* The following function fuses two loops. */
>
> void
> fuse_loops (struct loop *loop_a, struct loop *loop_b)
> {
> debug_loop (loop_a, 10);
> debug_loop (loop_b, 10);
> block_stmt_iterator bsi_a = bsi_start (loop_a->header);
> block_stmt_iterator bsi_a_last = bsi_last (loop_a->header);
> block_stmt_iterator bsi_b = bsi_last (loop_b->header);
> while (&bsi_a != &bsi_a_last)
> {
> bsi_move_before (&bsi_a, &bsi_b);
> fprintf (stderr, " transferred one statement from loop %d to
> loop %d ", loop_a->num, loop_b->num);
> bsi_next (&bsi_a);
> }
try
bsi_b = bsi_last (loop_b->header);
for (bsi_a = bsi_start (loop_a->header); !bsi_end_p (bsi_a); )
{
if (some condition) /* you probably want to skip labels and cond_exprs */
bsi_move_before (&bsi_a, &bsi_b);
else
bsi_next (&bsi_a);
}
Zdenek
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:48 +0200, Stelian Pop a écrit :
> Le mercredi 09 avril 2008 à 18:21 -0400, DJ Delorie a écrit :
> > > Maybe I should reserve a special register for this usage (say r0).
> >
> > That might be the only way, yes.
>
> Ok, I reserved r0 (BP_REGNUM) for such reloads, and I'm generating new
> instructions in LEGITIMIZE_RELOAD_ADDRESS to calculate the memory
> address:
[...]
Now it seems that the register moves are correctly dealt with, but I'm
still having the same problem on calls: just like indirect addressing,
indirect calls are allowed only on even registers.
My patterns look like:
(define_insn "*icall_value"
[(set (match_operand 0 "register_operand" "=r")
(call (mem:QI (match_operand:QI 1 "register_operand" "z"))
(match_operand:QI 2 "" "")))]
""
"icall (%1)"
[(set_attr "cc" "none")]
)
(define_expand "call_value"
[(set (match_operand 0 "register_operand" "=r")
(call (match_operand:QI 1 "memory_operand" "m")
(match_operand:QI 2 "general_operand" "")))]
""
{
if (GET_CODE (XEXP(operands[1], 0)) != REG)
XEXP(operands[1], 0) = force_reg (QImode, XEXP
(operands[1], 0));
}
)
This gives:
(insn 27 26 29 2 ../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564
(set (reg/f:QI 114)
(symbol_ref:QI ("__lshrqi3") [flags 0x41])) 1 {*movqi}
(expr_list:REG_EQUIV (symbol_ref:QI ("__lshrqi3") [flags 0x41])
(nil)))
...
(call_insn/u 30 29 31 2
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564 (set (reg:QI 4 r4)
(call (mem:QI (reg/f:QI 114) [0 S1 A16])
(const_int 0 [0x0]))) 37 {*icall_value} (expr_list:REG_DEAD
(reg:QI 5 r5)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:QI 5 r5))
(expr_list:REG_DEP_TRUE (use (reg:QI 4 r4 [ D.2373 ]))
(nil
And r114 gets reloaded into r1:
Reloads for insn # 30
Reload 0: reload_in (QI) = (symbol_ref:QI ("__lshrqi3") [flags 0x41])
EIGHT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (reg/f:QI 114)
reload_reg_rtx: (reg:QI 1 r1)
Which does not satisfy the *icall_value constraints:
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function
‘__mulhi3’:
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:570: error: insn does
not satisfy its constraints:
(call_insn/u 30 195 162 2
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564 (set (reg:QI 4 r4)
(call (mem:QI (reg:QI 1 r1) [0 S1 A16])
(const_int 0 [0x0]))) 37 {*icall_value}
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:QI 5 r5))
(expr_list:REG_DEP_TRUE (use (reg:QI 4 r4 [ D.2373 ]))
(nil
It seems that this reload doesn't pass through LEGITIMIZE_ADDRESS or
LEGITIMIZE_RELOAD_ADDRESS... How can I specify here to choose an EVEN_REGS
in place of the EIGHT_REGS (in fact it should choose one register in the
intersection of EIGHT and EVEN_REGS) ?
Thanks,
--
Stelian Pop <[EMAIL PROTECTED]>
GCC 4.2.4 Status Report (2008-04-10)
Status == The GCC 4.2 branch is open for commits under normal release branch rules. All fixes going on that branch should first have gone on trunk and 4.3 branch. I propose to build 4.2.4-rc1 once we have resolved what if any changes related to strict-overflow and pointer arithmetic should go on the branch. Any further 4.2 releases after 4.2.4 may depend on whether there is expressed user and developer interest in further releases from this branch, or whether 4.3 has been widely adopted in place of 4.2. Quality Data Priority # Change from Last Report --- --- P1 230 P2 137 + 2 P3 38 - 3 --- --- Total 198 - 1 Previous Report === http://gcc.gnu.org/ml/gcc/2008-03/msg01080.html I will send the next report for the 4.2 branch when making the 4.2.4-rc1 release candidate. -- Joseph S. Myers [EMAIL PROTECTED]
address taken problem
In the following code I marked the tree 'node.0' as address taken using
'c_mark_addressable'. Now in the assembly code, isn't the return value of the
second call to malloc completely discarded?
This problem does not arise in -O0. Here I'm using -O2.
main ()
{
void * D.2897;
struct node * D.2898;
struct node * node.0;
void * D.2900;
int * D.2901;
int * D.2902;
struct node * node;
D.2897 = malloc (8);
D.2898 = (struct node *) D.2897;
node = D.2898;
node.0 = node;
D.2900 = malloc (4);
D.2901 = (int *) D.2900;
node.0->item = D.2901;<--
node.0 = node;
D.2902 = node.0->item;
printf (&"%p %p\n"[0], D.2902, &node);
}
main:
.LFB5:
subq $24, %rsp
.LCFI0:
movl $8, %edi
call malloc
movl $4, %edi
movq %rax, 16(%rsp)
call malloc
movq 16(%rsp), %rax
leaq 16(%rsp), %rdx
movl $.LC0, %edi
movq (%rax), %rsi
xorl %eax, %eax
call printf
addq $24, %rsp
ret
The code that is generated when I do not modify the flag.
main:
.LFB5:
pushq %rbx
.LCFI0:
movl $8, %edi
subq $16, %rsp
.LCFI1:
call malloc
movl $4, %edi
movq %rax, %rbx
movq %rax, 8(%rsp)
call malloc
movq %rax, (%rbx)
movq 8(%rsp), %rax
leaq 8(%rsp), %rdx
movl $.LC0, %edi
movq (%rax), %rsi
xorl %eax, %eax
call printf
addq $16, %rsp
popq %rbx
ret
thanks,
-- dasarath
Re: Doubt about scheduling
"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > I got few doubts regarding the way in which scheduling works in gcc 4.1.2 > > 1. Will barrier insns gets scheduled along with other instructions? The scheduler works over regions. It doesn't look at barriers. > 2. When there is an unconditional jump in the instruction list, a > barrier instruction gets emitted after the unconditional jump as the > last instruction. Will this be regarded as an instruction when > counting the number of instructions in a region for scheduling > purposes? It shouldn't. > 3. After the end of scheduling a region can barrier remain as the last > instruction in the ready list unscheduled? Or in other words can ready > list be 'non-empty' after scheduling a region? As far as I know barriers won't get onto the ready list. If you see otherwise when running the compiler, then I am wrong. Ian
Re: Problem with reloading in a new backend...
> (call (mem:QI (match_operand:QI 1 "register_operand" "z")) Are you sure your "z" constraint only matches even numbered hard registers?
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:30 -0400, DJ Delorie a écrit :
> > (call (mem:QI (match_operand:QI 1 "register_operand" "z"))
>
> Are you sure your "z" constraint only matches even numbered hard
> registers?
Well, I think so:
enum reg_class
{
NO_REGS,
BP_REGS,
STACK_REGS,
EIGHT_REGS,
EVEN_REGS,
GENERAL_REGS,
ALL_REGS,
LIM_REG_CLASSES
};
#define N_REG_CLASSES ((int) LIM_REG_CLASSES)
#define REG_CLASS_CONTENTS \
{ \
{ 0x }, \
{ 0x0001 }, \
{ 0x8000 }, \
{ 0x00FF }, \
{ 0x }, \
{ 0x7FFE }, \
{ (1LL << FIRST_PSEUDO_REGISTER) - 1 }\
}
...
(define_register_constraint "z" "EVEN_REGS"
"Even registers (r0,r2,r4, @dots{} r30)")
--
Stelian Pop <[EMAIL PROTECTED]>
Re: Problem with reloading in a new backend...
I noticed Stack register is missing from ALL_REGS. Are registers 16bit? Is just one required for pointer? Andy
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:56 -0400, [EMAIL PROTECTED] a écrit : > I noticed > > > Stack register is missing from ALL_REGS. No, it is not. It is missing from GENERAL_REGS but not from ALL_REGS. > Are registers 16bit? Yes. > Is just one required for pointer? For now, yes, I chose to support only 2^16 RAM addresses. In fact, this microcontroller is able to address 2^24, and two registers are used for indirect accesses (Rx and Rx+1, where x is even), this is the reason why only even registers are allowed in indirect addressing... -- Stelian Pop <[EMAIL PROTECTED]>
gcc-4.3-20080410 is now available
Snapshot gcc-4.3-20080410 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080410/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 134179 You'll find: gcc-4.3-20080410.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080410.tar.bz2 C front end and core compiler gcc-ada-4.3-20080410.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080410.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080410.tar.bz2 C++ front end and runtime gcc-java-4.3-20080410.tar.bz2 Java front end and runtime gcc-objc-4.3-20080410.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080410.tar.bz2The GCC testsuite Diffs from 4.3-20080403 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
A doubt about constraint modifiers
Hello all, I have noticed that when strict_low_part is used in a patten we need to use '+' as the constraint modifier if any constraints are used in the patterns. Why is this so? Regards, Shafi
Re: Fusing two loops
Hi Zdenek,
Thanks.
Sandeep.
On Thu, Apr 10, 2008 at 7:29 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > The error is rectified. The bug is in the function that calls fuse_loops().
> > Now I am trying to transfer all the statements, using code -
> >
> > /* The following function fuses two loops. */
> >
> > void
> > fuse_loops (struct loop *loop_a, struct loop *loop_b)
> > {
> > debug_loop (loop_a, 10);
> > debug_loop (loop_b, 10);
> > block_stmt_iterator bsi_a = bsi_start (loop_a->header);
> > block_stmt_iterator bsi_a_last = bsi_last (loop_a->header);
> > block_stmt_iterator bsi_b = bsi_last (loop_b->header);
> > while (&bsi_a != &bsi_a_last)
> > {
> > bsi_move_before (&bsi_a, &bsi_b);
> > fprintf (stderr, " transferred one statement from loop %d to
> > loop %d ", loop_a->num, loop_b->num);
> > bsi_next (&bsi_a);
> > }
>
> try
>
>
> bsi_b = bsi_last (loop_b->header);
>
> for (bsi_a = bsi_start (loop_a->header); !bsi_end_p (bsi_a); )
> {
> if (some condition) /* you probably want to skip labels and cond_exprs */
>
> bsi_move_before (&bsi_a, &bsi_b);
> else
> bsi_next (&bsi_a);
> }
>
> Zdenek
>
