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

[Joel Soete <soete.joel@scarlet.be>]

Hello Grant,

Grant Grundler wrote:
> On Thu, Jun 26, 2008 at 07:28:03AM +0100, Joel Soete wrote:
>> Just for remind:
>>
>> Joel Soete wrote:
>>  >
>>  >
>> [snip]
>>  >>> 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 seems to make better what I want:
>>         __asm__ __volatile__ (
>>         "lci    %%r0(%%sr1, %2), %0\n"
>>         "\textru        %0,19,12,%0\n"
>>         "\tdepw         %0,15,12,%1\n"
>>         : "+r" (ci), "+r" (pa)
>>         : "r" (vba)
>>         : "memory"
> 
> Why the "memory"? This asm code isn't modifying memory at all.
> 
well I certainly still have wrongly understand what "memory" clobber means but for me "pa" is a memory location modified 
(the plus sign in '"+r" (pa)' and that either after 64bit computation or 32bit initialization pa=0).
But your comment make me fill I am again wrong (well definitively C is not my language ;-) .)

>>         );
>>
>>
>> in <ccio_map_sg>
>>   200:	06 80 53 13 	lci r0(sr1,r20),r19		      |	 200:	08 1a 02 54 	copy r26,r20
>>   204:	d2 73 1a 74 	extrw,u r19,19,12,r19		      |	 204:	06 a0 53 14 	lci
>> r0(sr1,r21),r20
>>   208:	08 1a 02 5c 	copy r26,ret0			      |	 208:	d2 94 1a 74 	extrw,u
>> r20,19,12,r20
>>   20c:	d7 93 0e 14 	depw r19,15,12,ret0		      |	 20c:	d7 94 0e 14 	depw
>> r20,15,12,ret0
>>   210:	0e dc 12 80 	stw ret0,0(r22)				 210:	0e dc 12 80 	stw ret0,0(r22)
>>   214:	06 c0 12 80 	fdc r0(r22)				 214:	06 c0 12 80 	fdc r0(r22)
>>   218:	00 00 04 00 	sync					 218:	00 00 04 00 	sync
>>
>> J.
>>
>> PS: I don't yet understand why kernel panicing when I try to get rid to
>> reserve 'ci' variable and use in place a gr as r19 (even if clobbered), the
>> produced object seems ok but resulting kernel panicing (even after a full
>> rebuild after a make distclean???)
> 
> What's wrong with "ci" variable? It's just another register.
well the idea is that "ci" variable is just there as a tmp variable just used in this asm code, right.
so why not simply get rid of its declaration (btw save a line of code ;-)) and just use a common temporay reg as r19?

but what I show above is just a 'diff -y' between a objdump's hunk of ccio-dma.o:
on the left side what gcc produce with the original code (3 different asm lines) (this kernel was well booting fine)
on the right side what same compile produce with new code (1 asm line).

Otoh, based on my few knowldge on parisc asm, it seems to me that something like:
          __asm__ __volatile__ (
          "lci    %%r0(%%sr1, %1), %%r19\n"
          "\textru        %%r19,19,12,%%r19\n"
          "\tdepw         %%r19,15,12,%0\n"
          : "+r" (pa)
          : "r" (vba)
          : "r19")

would do the same job, but all my test results was a panicing kernel???
(even thought if I am diffing 2 objdump of the only ccio-dma.o, it looks like gr are just used differently. but may be did I 
missed another wrong stuff).

That said, nothing of that help to fixe ccio-dma driver issue ;-(

My latest hope is relayfs to grab more debug info (I just need a bit more free time).

> C compiler will allocate it and then we pass it to the asm().
> 
> And are you sure it's ok to use r19?
> 
yes that was the only lines, I was working on.

Tx,
	J.

> hth,
> grant
> 
> 
>