All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Soete <soete.joel@scarlet.be>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: rubisher <rubisher@scarlet.be>, linux-parisc@vger.kernel.org
Subject: Re: in ccio_io_pdir_entry(), BUG_ON() seems to break gcc-4.2	optimization?
Date: Thu, 19 Jun 2008 19:44:43 +0000	[thread overview]
Message-ID: <485AB72B.2090304@scarlet.be> (raw)
In-Reply-To: <20080619160441.GA6049@colo.lackof.org>



Grant Grundler wrote:
> On Sun, Jun 15, 2008 at 12:37:25PM +0000, rubisher wrote:
>> 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);
> ...
>> 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.
> 
> ...
>> 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.

>> 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(),
> 
> Right. That should be a clue. :)
> 
> hth,
> grant
> 
Tx again,
	J.

ps: ccio_io_pdir_entry() seems to works fine without 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.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
>> the body of a message to majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

  reply	other threads:[~2008-06-19 19:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-15 12:37 in ccio_io_pdir_entry(), BUG_ON() seems to break gcc-4.2 optimization? rubisher
2008-06-16 11:37 ` in ccio_io_pdir_entry(),BUG_ON() " rubisher
2008-06-19 16:04 ` in ccio_io_pdir_entry(), BUG_ON() " Grant Grundler
2008-06-19 19:44   ` Joel Soete [this message]
2008-06-19 22:48     ` John David Anglin
2008-06-19 22:41   ` in ccio_io_pdir_entry(), BUG_ON() seems to break gcc-4.2 John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
2008-06-20  6:37 in ccio_io_pdir_entry(),BUG_ON() seems to break gcc-4.2 optimization? Joel Soete
2008-06-26  6:28 Joel Soete
2008-06-28 20:23 ` Grant Grundler
2008-06-28 22:26   ` Joel Soete
2008-06-28 22:45     ` John David Anglin
2008-06-29 20:52     ` Grant Grundler
2008-06-30 18:28       ` Joel Soete
2008-07-02  4:28         ` Grant Grundler
2008-07-02 18:01           ` Joel Soete
2008-07-07 15:28             ` Grant Grundler
2008-07-08  9:04 Joel Soete

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=485AB72B.2090304@scarlet.be \
    --to=soete.joel@scarlet.be \
    --cc=grundler@parisc-linux.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=rubisher@scarlet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.