Skip to contentSkip to conversation

in ccio_io_pdir_entry(), BUG_ON() seems to break gcc-4.2 optimization?

DISCUSSION rubisher 4 participants 6 messages Jun 15, 2008 – Jun 19, 2008

lore
Share & tools
lore

rubisher

author
#0 lore raw

Hello all,

looking at this hunk:
void CCIO_INLINE
ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, unsigned long vba,
unsigned long hints)

{
        register unsigned long pa;
        register unsigned long ci; /* coherent index */

        /* We currently only support kernel addresses */
        BUG_ON(sid != KERNEL_SPACE);

        mtsp(sid,1);

[snip]

        pa = virt_to_phys(vba);
        asm volatile("depw  %1,31,12,%0" : "+r" (pa) : "r" (hints));
        ((u32 *)pdir_ptr)[1] = (u32) pa;

[snip]

        pa = 0;
[snip]
        asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
        asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
        asm volatile ("depw  %1,15,12,%0" : "+r" (pa) : "r" (ci));

        ((u32 *)pdir_ptr)[0] = (u32) pa;

[snip]

        asm volatile("fdc %%r0(%0)" : : "r" (pdir_ptr));
        asm volatile("sync");
}

(I just remove comments and 64bit stuff)

and I noticed that resulting code looks like:

   0:   cb 39 a0 60     movb,<> r25,r25,38 <ccio_io_pdir_entry+0x38>
   4:   34 1c 00 00     ldi 0,ret0
   8:   00 1c 58 20     mtsp ret0,sr1
   c:   22 60 0e 01     ldil L%-10000000,r19
  10:   0a 78 0a 13     add,l r24,r19,r19
  14:   d6 77 0c 14     depw r23,31,12,r19
  18:   0f 53 12 88     stw r19,4(r26)
  1c:   07 00 53 1c     lci r0(sr1,r24),ret0
  20:   d3 9c 1a 74     extrw,u ret0,19,12,ret0
  24:   d7 3c 0e 14     depw ret0,15,12,r25
  28:   0f 59 12 80     stw r25,0(r26)
  2c:   07 40 12 80     fdc r0(r26)
  30:   00 00 04 00     sync
  34:   e8 40 c0 02     bv,n r0(rp)
  38:   03 ff e0 1f     break 1f,1fff
  3c:   e8 1f 1f f7     b,l,n 3c <ccio_io_pdir_entry+0x3c>,r0

Disassembly of section .text.ccio_proc_bitmap_open:

And my worry was about lines 4: and 8:.
According to the C code, I don't understand why optimization want to initialize sr1 to 0 while it should be set to r25 (i.e. arg1)?

Otoh, the sba botherhood code didn't showing the same behaviour:

   0:   22 a0 0e 01     ldil L%-10000000,r21
   4:   34 1c 00 00     ldi 0,ret0
   8:   34 1d 20 01     ldi -1000,ret1
   c:   0a b8 0a 15     add,l r24,r21,r21
  10:   08 15 02 56     copy r21,r22
  14:   34 15 00 00     ldi 0,r21
  18:   0b 95 02 15     and r21,ret0,r21
  1c:   0b b6 02 16     and r22,ret1,r22
  20:   00 19 58 20     mtsp r25,sr1
  24:   07 00 53 13     lci r0(sr1,r24),r19
  28:   d2 73 1a 6c     extrw,u r19,19,20,r19
  2c:   23 80 00 01     ldil L%-80000000,ret0
  30:   34 1d 00 00     ldi 0,ret1

but didn't start with BUG_ON(), I simply try to remove this from ccio code and get a better result:
00000000 <ccio_io_pdir_entry>:

   0:   00 19 58 20     mtsp r25,sr1
   4:   23 80 0e 01     ldil L%-10000000,ret0
   8:   0b 98 0a 1c     add,l r24,ret0,ret0
   c:   d7 97 0c 14     depw r23,31,12,ret0
  10:   0f 5c 12 88     stw ret0,4(r26)
  14:   07 00 53 18     lci r0(sr1,r24),r24
  18:   d3 18 1a 74     extrw,u r24,19,12,r24
  1c:   34 1c 00 00     ldi 0,ret0
  20:   d7 98 0e 14     depw r24,15,12,ret0
  24:   0f 5c 12 80     stw ret0,0(r26)
  28:   07 40 12 80     fdc r0(r26)
  2c:   00 00 04 00     sync
  30:   e8 40 c0 02     bv,n r0(rp)

Disassembly of section .init.text:

But this time, it seems not consider assembly:

        asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
        asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
        asm volatile ("depw  %1,15,12,%0" : "+r" (pa) : "r" (ci));

as a 'volatile' block and insert line 1c:
This could may be solved by re-write as an one 'volatile' asm block like:

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba));

and even add a clobber 'memory'

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba)
	: "memory");

But I have no clue how to restore BUG_ON() and avoid wrong optimization?

Any idea?

Tia,

	r.
author
#1 lore raw

Re: in ccio_io_pdir_entry(),BUG_ON() seems to break gcc-4.2 optimization?

wierd, though.

Quoted 7 lines · rubisher <rubisher <at> scarlet.be> writes:

Hello all,

looking at this hunk:
void CCIO_INLINE
ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, unsigned long vba,
unsigned long hints)

Quoted 7 lines
{
         register unsigned long pa;
         register unsigned long ci; /* coherent index */

         /* We currently only support kernel addresses */
         BUG_ON(sid != KERNEL_SPACE);

no pb to get rid of this BUG_ON(): each place I see it called sid == KERNEL_SPACE the optimized produced code looks so Ok

[snip]

Quoted 24 lines

But this time, it seems not consider assembly:

         asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
         asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
         asm volatile ("depw  %1,15,12,%0" : "+r" (pa) : "r" (ci));

as a 'volatile' block and insert line 1c:
This could may be solved by re-write as an one 'volatile' asm block like:

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba));

and even add a clobber 'memory'

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba)
	: "memory");
Quoted 2 lines

But I have no clue how to restore BUG_ON() and avoid wrong optimization?

But here is what is very wierd, I tested severall re-writen on this code amoung latest:

	asm volatile (
	"lci %%r0(%%sr1, %1), %%r19"
	"\textru        %%r19,19,12,%%r19\n"
	"\tdepw         %%r19,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba)
	: "r19" );

but this system failed to boot on ncr_attach: pim info seems to point out to this place:
PROCESSOR PIM INFORMATION

----------------- Processor 0 HPMC Information ------------------

Timestamp = Mon Jun 16 09:50:32 GMT 2008 (20:08:06:16:09:50:32)

HPMC Chassis Codes = 0xcbf0 0x5002 0x7d03 0x5402 0x5508 0xcbf2

                     0xcbfc  

General Registers 0 - 31

00-03  0000000000000000  18711a0000001194  0000000010514bf8  000000001fd48000
04-07  0000000000000003  0000000010520308  000000001fdf2400  000000001fc20414
08-11  000000001049f3d8  000000001fc20088  000000001051ce20  00000000104e03cc
12-15  000000001fd4802c  000000001fdf2704  0000000010425000  0000000010425000
16-19  0000000010403b78  0000000010403ba8  0000000010403bb8  0000000000024800
20-23  00000000000a142c  00000000000f4240  000000001fd48000  0000000000001458
24-27  0000000000024800  0000000000000000  000000001fd48000  000000001047de20
28-31  0000000000000001  61c4680000004650  000000001fc20540  000000001029bfdc

Control Registers 0 - 31

00-03  0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07  0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11  0000000000000000  0000000000000000  00000000000000c0  000000000000001d
12-15  0000000000000000  0000000000000000  0000000000110000  00000000e1000000
16-19  000000248ca1a027  0000000000000000  0000000010514c6c  00000000d39c1bfd
20-23  000000009227ffc4  000000000102482c  000000ff0004f90f  0000000080000000
24-27  00000000004c2000  00000000004c2000  00000000aaaaaaaa  00000000aaaaaaaa
28-31  00000000000003d0  0000000011111111  000000001fc20000  0000000011111111

Space Registers 0 - 7

00-03  00000000          00000000          00000000          00000000
04-07  00000000          00000000          00000000          00000000
IIA Space                    = 0x0000000000000000
IIA Offset                   = 0x0000000010514c70
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x00305004
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0x000000fff1004817
System Requestor Address     = 0xfffffffffffa0000
Check Summary                = 0x8000000810284000
Available Memory             = 0x0000000010000000
CPU Diagnose Register 2      = 0x0301000004000004
CPU Status Register 0        = 0x1440020000000000
CPU Status Register 1        = 0x8000000800000000
SADD LOG                     = 0x0000000100000001
Read Short LOG               = 0xc10010fff1004817

----------------- Processor 0 LPMC Information ------------------

Check Type                   = 0x00000000
IC Parity Info               = 0x00000000
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x00000000
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0x0000000000000000
System Requestor Address     = 0x0000000000000000

----------------- Processor 0 TOC Information -------------------

General Registers 0 - 31

00-03  0000000000000000  000000000aba9500  00000000f005d12c  0000002d110b5065
04-07  0000000000000000  fffffffff0101120  00000000000f4240  0000000000000005
08-11  00000000f0102cd4  000000001fc20088  000000001051ce20  00000000104e03cc
12-15  000000001fd4802c  000000001fdf2704  0000000010425000  0000000010425000
16-19  0000000010403b78  0000000010403ba8  0000000010403bb8  fffffffff0160007
20-23  0000000000000001  00000000000f4240  000000001fd48000  0000000000000000
24-27  0000000000000000  0000000000000000  0000002d13066c03  fffffffff0102400
28-31  0000002d1bc5e565  0301000004000004  fffffffff0102e30  0301000004000004

Control Registers 0 - 31

00-03  0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07  0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11  0000000000000000  0000000000000000  00000000000000c0  000000000000001d
12-15  0000000000000000  0000000000000000  000000fff0010000  0000000000000000
16-19  0000002d130a7a0d  0000000000000000  00000000f005d154  000000000804025c
20-23  000000009227c3c0  c000000040902e44  0000000000291008  0000000080000000
24-27  00000000004c2000  00000000004c2000  00000000aaaaaaaa  00000000aaaaaaaa
28-31  00000000000003d0  0000000011111111  000000001fc20000  0000000011111111

Space Registers 0 - 7

00-03  00000000          00000000          00000000          00000000
04-07  00000000          00000000          00000000          00000000
IIA Space                    = 0x0000000000000000
IIA Offset                   = 0x00000000f005d134
CPU State                    = 0x9e000001

Memory Error Log Information:

Timestamp = Mon Jun 16 09:50:32 GMT 2008 (20:08:06:16:09:50:32)

Trans Addr Central Bus

Status  Requestor     id    par  CP  AD  DV       Address/Data
------  ----------  -----  ----  --  --  --  ---------------------

0x14 0xfffa0000 0x00 0x0 0 0 0 0x00000000 0x00000000

                                                    Memory
                                  ECC Reg     Address      Data
                                 ----------  ---------- ----------

                                 0x00000000  0x00000000 0x00000000
                                                        0x00000000
                                                        0x00000000
                                                        0x00000000
                                                        0x00000000

I/O Module Error Log Information:

Timestamp = Mon Jun 16 09:50:32 GMT 2008 (20:08:06:16:09:50:32)

Bus HPA Module Type Path Slt Md Sev Estat Requestor Responder
--- ---------- ---------------- -------- -- -- ---- ----- ---------- ----------

 0  0xfff88000 I/O Adapter      8         2  0  he   0x04 0xf1004000 0x000a1420
 0  0xfff8a000 I/O Adapter      10        2  2  he   0x0d 0x00000000 0x00000000

IO Bus Converter Log
--------------------

IOA0 HPA = 0xfff88000
IOA0 UBC_IO_CONTROL = 0x00020080

GSC1 HPA            = 0xf1000001
IOA0 IO_IO_LO       = 0xf0800000
IOA0 IO_IO_HI       = 0xf17f0000
IOA0 IO_IO_LO_HV    = 0xfc000000
IOA0 IO_IO_HI_HV    = 0xfff80000

IOA1 HPA = 0xfff8a000
IOA1 UBC_IO_CONTROL = 0x00020080

GSC2 HPA            = 0xf1800001
IOA1 IO_IO_LO       = 0xf1800000
IOA1 IO_IO_HI       = 0xf2000000
IOA1 IO_IO_LO_HV    = 0x00000000
IOA1 IO_IO_HI_HV    = 0x00000000

while IAOQ point to
IIA Offset = 0x0000000010514c70
...

e.g. IAOQ = 0x0000000010514c70

Parse IAOQ = 0x0000000010514c70 for CPU[0]

Func: ncr_attach, Off: 0xc4c, Addr: 0x10514c70

	...

10514c60: 80 95 20 28 cmpb,= r21,r4,10514c7c <.L1517+0x660>

	...

10514c70: 87 80 3f d7 cmpib,=,n 0,ret0,10514c60 <.L1517+0x644>
10514c74: 34 84 00 02 ldo 1(r4),r4
10514c78: 08 03 02 5a copy r3,r26
10514c7c: 34 19 00 c8 ldi 64,r25

Any idea what I missed in this chg?

Tia,
r.

#2 lore raw
In reply to rubisher
Quoted 12 lines · rubisher

Hello all,

looking at this hunk:
void CCIO_INLINE
ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, unsigned long vba,
unsigned long hints)

{
        register unsigned long pa;
        register unsigned long ci; /* coherent index */

        /* We currently only support kernel addresses */
        BUG_ON(sid != KERNEL_SPACE);

...

Quoted 3 lines

and I noticed that resulting code looks like:

   0:   cb 39 a0 60     movb,<> r25,r25,38 <ccio_io_pdir_entry+0x38>
   4:   34 1c 00 00     ldi 0,ret0

The BUG_ON is causing the movb to be inserted. And then the compiler knows the value is zero and can either copy from a register or "load immediate 0". It probably chose the "ldi 0" because it avoids register interlocks and can always be executed.

The movb will either branch to +0x38 (and nullifies the delay slot) or execute the ldi. So it looks right to me.

BTW, I think the BUG_ON can go away. It's good for debugging but doesn't need to be in every kernel.

...

Quoted 3 lines

And my worry was about lines 4: and 8:.
According to the C code, I don't understand why optimization want to initialize sr1 to 0 while it should be set to r25 (i.e. arg1)?

Does the BUG_ON explaination make sense to you?

Quoted 16 lines

Otoh, the sba botherhood code didn't showing the same behaviour:

   0:   22 a0 0e 01     ldil L%-10000000,r21
   4:   34 1c 00 00     ldi 0,ret0
   8:   34 1d 20 01     ldi -1000,ret1
   c:   0a b8 0a 15     add,l r24,r21,r21
  10:   08 15 02 56     copy r21,r22
  14:   34 15 00 00     ldi 0,r21
  18:   0b 95 02 15     and r21,ret0,r21
  1c:   0b b6 02 16     and r22,ret1,r22
  20:   00 19 58 20     mtsp r25,sr1
  24:   07 00 53 13     lci r0(sr1,r24),r19
  28:   d2 73 1a 6c     extrw,u r19,19,20,r19
  2c:   23 80 00 01     ldil L%-80000000,ret0
  30:   34 1d 00 00     ldi 0,ret1
Quoted 1 line

but didn't start with BUG_ON(),

Right. That should be a clue. :)

hth,
grant

Quoted 52 lines

I simply try to remove this from ccio code
and get a better result:
00000000 <ccio_io_pdir_entry>:

   0:   00 19 58 20     mtsp r25,sr1
   4:   23 80 0e 01     ldil L%-10000000,ret0
   8:   0b 98 0a 1c     add,l r24,ret0,ret0
   c:   d7 97 0c 14     depw r23,31,12,ret0
  10:   0f 5c 12 88     stw ret0,4(r26)
  14:   07 00 53 18     lci r0(sr1,r24),r24
  18:   d3 18 1a 74     extrw,u r24,19,12,r24
  1c:   34 1c 00 00     ldi 0,ret0
  20:   d7 98 0e 14     depw r24,15,12,ret0
  24:   0f 5c 12 80     stw ret0,0(r26)
  28:   07 40 12 80     fdc r0(r26)
  2c:   00 00 04 00     sync
  30:   e8 40 c0 02     bv,n r0(rp)

Disassembly of section .init.text:

But this time, it seems not consider assembly:

        asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
        asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
        asm volatile ("depw  %1,15,12,%0" : "+r" (pa) : "r" (ci));

as a 'volatile' block and insert line 1c:
This could may be solved by re-write as an one 'volatile' asm block like:

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba));

and even add a clobber 'memory'

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba)
	: "memory");

But I have no clue how to restore BUG_ON() and avoid wrong optimization?

Any idea?

Tia,

	r.

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 26 lines · Grant Grundler
Quoted 12 lines · rubisher

Hello all,

looking at this hunk:
void CCIO_INLINE
ccio_io_pdir_entry(u64 *pdir_ptr, space_t sid, unsigned long vba,
unsigned long hints)

{
        register unsigned long pa;
        register unsigned long ci; /* coherent index */

        /* We currently only support kernel addresses */
        BUG_ON(sid != KERNEL_SPACE);

...

Quoted 3 lines

and I noticed that resulting code looks like:

   0:   cb 39 a0 60     movb,<> r25,r25,38 <ccio_io_pdir_entry+0x38>
   4:   34 1c 00 00     ldi 0,ret0

The BUG_ON is causing the movb to be inserted. And then the compiler knows the value is zero and can either copy from a register or "load immediate 0". It probably chose the "ldi 0" because it avoids register interlocks and can always be executed.

The movb will either branch to +0x38 (and nullifies the delay slot) or execute the ldi. So it looks right to me.

Quoted 9 lines

BTW, I think the BUG_ON can go away. It's good for debugging but doesn't need to be in every kernel.

...

Quoted 2 lines

And my worry was about lines 4: and 8:.
According to the C code, I don't understand why optimization want to initialize sr1 to 0 while it should be set to r25 (i.e. arg1)?

Does the BUG_ON explaination make sense to you?

Well I nerver imagine that a compiler can make proof of this kind of induction spirit ;-) but that's give the sense, tx.

Quoted 15 lines
Quoted 15 lines

Otoh, the sba botherhood code didn't showing the same behaviour:

   0:   22 a0 0e 01     ldil L%-10000000,r21
   4:   34 1c 00 00     ldi 0,ret0
   8:   34 1d 20 01     ldi -1000,ret1
   c:   0a b8 0a 15     add,l r24,r21,r21
  10:   08 15 02 56     copy r21,r22
  14:   34 15 00 00     ldi 0,r21
  18:   0b 95 02 15     and r21,ret0,r21
  1c:   0b b6 02 16     and r22,ret1,r22
  20:   00 19 58 20     mtsp r25,sr1
  24:   07 00 53 13     lci r0(sr1,r24),r19
  28:   d2 73 1a 6c     extrw,u r19,19,20,r19
  2c:   23 80 00 01     ldil L%-80000000,ret0
  30:   34 1d 00 00     ldi 0,ret1
Quoted 7 lines
Quoted 1 line

but didn't start with BUG_ON(),

Right. That should be a clue. :)

hth,
grant

Tx again,

	J.

ps: ccio_io_pdir_entry() seems to works fine without BUG_ON().

Quoted 57 lines
Quoted 44 lines

I simply try to remove this from ccio code and get a better result:
00000000 <ccio_io_pdir_entry>:

   0:   00 19 58 20     mtsp r25,sr1
   4:   23 80 0e 01     ldil L%-10000000,ret0
   8:   0b 98 0a 1c     add,l r24,ret0,ret0
   c:   d7 97 0c 14     depw r23,31,12,ret0
  10:   0f 5c 12 88     stw ret0,4(r26)
  14:   07 00 53 18     lci r0(sr1,r24),r24
  18:   d3 18 1a 74     extrw,u r24,19,12,r24
  1c:   34 1c 00 00     ldi 0,ret0
  20:   d7 98 0e 14     depw r24,15,12,ret0
  24:   0f 5c 12 80     stw ret0,0(r26)
  28:   07 40 12 80     fdc r0(r26)
  2c:   00 00 04 00     sync
  30:   e8 40 c0 02     bv,n r0(rp)

Disassembly of section .init.text:

But this time, it seems not consider assembly:

        asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
        asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
        asm volatile ("depw  %1,15,12,%0" : "+r" (pa) : "r" (ci));

as a 'volatile' block and insert line 1c:
This could may be solved by re-write as an one 'volatile' asm block like:

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba));

and even add a clobber 'memory'

	asm volatile (
	"lci %%r0(%%sr1, %1), %1"
	"\textru        %1,19,12,%1\n"
	"\tdepw         %1,15,12,%0\n"
	: "=r" (pa)
	: "r" (vba)
	: "memory");

But I have no clue how to restore BUG_ON() and avoid wrong optimization?

Any idea?

Quoted 7 lines

Tia,

	r.

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
Quoted 3 lines
Quoted 2 lines

Does the BUG_ON explaination make sense to you?

Well I nerver imagine that a compiler can make proof of this kind of induction spirit ;-) but that's give the sense, tx.

Yes, the current compiler eliminates a lot of dead code based on induction. This occurs a lot when functions are inlined, etc. Makes debugging a real problem.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#5 lore raw

Re: in ccio_io_pdir_entry(), BUG_ON() seems to break gcc-4.2

In reply to Grant Grundler
Quoted 6 lines
Quoted 1 line
   4:   34 1c 00 00     ldi 0,ret0

The BUG_ON is causing the movb to be inserted. And then the compiler knows the value is zero and can either copy from a register or "load immediate 0". It probably chose the "ldi 0" because it avoids register interlocks and can always be executed.

This might not be correct with gnu as, but I think "ldi 0" is done as

	or r0,r0,ret0

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)