[Bug] subword handling for DI modes

[Bug] subword handling for DI modes

[Ben Elliston]

Hi,

What follows is a minimal CPU description that demonstrates a problem
I'm having with the (subword ..) rtx.  In the semantics for my
fictitious ADD instruction, I am taking the 0th SI subword from a
DI-sized operand, yet the generated simulator code thinks it is SI:

  {
    DI opval = SUBWORDSISI (CPU (h_reg));
    CPU (h_reg) = opval;
    TRACE_RESULT (current_cpu, abuf, "reg", 'D', opval);
  }

Here is a minimal test case that reproduces the problem.  Does anyone
have any ideas?  Thanks,

Ben



(include "simplify.inc")

(define-arch
  (name foo)
  (comment "foo")
  (insn-lsb0? #t)
  (machs foo1)
  (isas yep)
)

(define-isa
  (name yep)
  (comment "yep")
  (base-insn-bitsize 32)
)

(define-cpu
  (name foof)
  (comment "foo family")
  (endian either)
  (word-bitsize 32)
)

(define-mach
  (name foo1)
  (comment "foo1 cpu")
  (cpu foof)
)

(define-model
  (name foo)
  (comment "foo")
  (mach foo1)
  (unit u-exec "Execution unit" ()
	1 1 ; issue done
	() () () ())
)

(define-hardware
  (name h-reg)
  (comment "64-bit register")
  (type register DI)
)

(dnf  f-reg         "Register"                  ()  31 6)
(dnf  f-rest        "Rest of instruction"       ()  25 26)

(dnop reg           "Register"                  ()  h-reg f-reg)

(dni add "Add"
     ()
     "add $reg"
     (+ reg (f-rest 0))
     (set reg (subword SI reg 0))
     ()
)

Re: [Bug] subword handling for DI modes

[Ben Elliston]

I wrote:

   Here is a minimal test case that reproduces the problem.  Does anyone
   have any ideas?  Thanks,

        (set reg (subword SI reg 0))

FYI, I was able to work around this by using:

	(subword SI (reg h-reg) 0)

So it seems something is amiss in the determination of the operand's mode.

Ben

Re: [Bug] subword handling for DI modes

[Frank Ch. Eigler]

On Tue, Oct 10, 2000 at 03:31:55PM +1100, Ben Elliston wrote:
> [...]
> FYI, I was able to work around this by using:
> 	(subword SI (reg h-reg) 0)
> So it seems something is amiss in the determination of the operand's mode.

While I don't have a fix for this problem, let me make the observation
that the interpretation of the subword number (the last argument) is
pretty iffy.  Some cgen code interprets it an endian-dependent manner
(as in "0th subword as laid out in memory"), and some other code in
endian-independent (as in "0th among least->most significant subwords").

I think the endinan-independent interpretation is more useful, but to
switch over to it would require a fair bit of testing.  Still, it's
important to fix this one way or the other.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE593+0VZbdDOm/ZT0RAiPUAJ9g+Nrv6eiZW2HE9nRTdMlxc+AKWgCdFb73
RkHCbNL+u/OI6OATSSl/9r0=
=eb8F
-----END PGP SIGNATURE-----

Re: [Bug] subword handling for DI modes

[Ben Elliston]

   While I don't have a fix for this problem, let me make the observation
   that the interpretation of the subword number (the last argument) is
   pretty iffy.  Some cgen code interprets it an endian-dependent manner
   (as in "0th subword as laid out in memory"), and some other code in
   endian-independent (as in "0th among least->most significant
   subwords").

I think the manual describes this predicament.

   I think the endinan-independent interpretation is more useful, but to
   switch over to it would require a fair bit of testing.  Still, it's
   important to fix this one way or the other.

I agree -- my preferred usage is for (subword <mode> 0) to give me bits 0 to
sizeof(mode) - 1.  I hope it can be fixed soon.

Ben

Re: [Bug] subword handling for DI modes

[Doug Evans]

Ben Elliston writes:
 >    While I don't have a fix for this problem, let me make the observation
 >    that the interpretation of the subword number (the last argument) is
 >    pretty iffy.  Some cgen code interprets it an endian-dependent manner
 >    (as in "0th subword as laid out in memory"), and some other code in
 >    endian-independent (as in "0th among least->most significant
 >    subwords").
 > 
 > I think the manual describes this predicament.

It does.
IIRC (but I wouldn't bet the farm on it) the rules follow gcc's SUBREG.

 >    I think the endinan-independent interpretation is more useful, but to
 >    switch over to it would require a fair bit of testing.  Still, it's
 >    important to fix this one way or the other.
 > 
 > I agree -- my preferred usage is for (subword <mode> 0) to give me bits 0 to
 > sizeof(mode) - 1.  I hope it can be fixed soon.

Re: [Bug] subword handling for DI modes

[Doug Evans]

Ben Elliston writes:
 > I wrote:
 > 
 >    Here is a minimal test case that reproduces the problem.  Does anyone
 >    have any ideas?  Thanks,
 > 
 >         (set reg (subword SI reg 0))
 > 
 > FYI, I was able to work around this by using:
 > 
 > 	(subword SI (reg h-reg) 0)
 > 
 > So it seems something is amiss in the determination of the operand's mode.

Here is my tentative proposed patch.

The bug happens when "compiling" the semantics of the insn.
semantic-compile will call rtx-traverse which will use the mode
of the result as the default mode for operand0.  subword is not a
normal rtx; the mode of operand0 is its own mode, not the mode of
the result of the rtx.

2000-10-26  Doug Evans  <dje@casey.transmeta.com>

	* rtx-funcs.scm (subword): Change mode spec of operand0 from OP0
	to ANY.

*** rtx-funcs.scm.~1~	Thu Jul 27 21:11:52 2000
--- rtx-funcs.scm	Thu Oct 26 21:49:11 2000
***************
*** 426,439 ****
  
  ; GCC's subreg.
  ; Called subword 'cus it's not exactly subreg.
! ; Word numbering is from most signficant (word 0) to least (word N-1).
  ; ??? May also want an endian dependent word ordering.  That can be
  ; implemented on top of or beside this.
  ; ??? GCC plans to switch to SUBREG_BYTE.  Keep an eye out for the switch
  ; (which is extensive so probably won't happen anytime soon).
  
  (drn (subword &options &mode value word-num)
!      (OPTIONS NUMMODE RTX RTX) (NA NA OP0 INT)
       ARG
       #f
  )
--- 426,444 ----
  
  ; GCC's subreg.
  ; Called subword 'cus it's not exactly subreg.
! ; Word numbering is from most significant (word 0) to least (word N-1).
  ; ??? May also want an endian dependent word ordering.  That can be
  ; implemented on top of or beside this.
  ; ??? GCC plans to switch to SUBREG_BYTE.  Keep an eye out for the switch
  ; (which is extensive so probably won't happen anytime soon).
+ ;
+ ; The mode spec of operand0 use to be OP0, but subword is not a normal rtx.
+ ; The mode of operand0 is not necessarily the same as the mode of the result,
+ ; and code which analyzes it would otherwise use the result mode (specified by
+ ; `&mode') for the mode of operand0.
  
  (drn (subword &options &mode value word-num)
!      (OPTIONS NUMMODE RTX RTX) (NA NA ANY INT)
       ARG
       #f
  )

Re: [Bug] subword handling for DI modes

[Ben Elliston]

Hi Doug,

   The bug happens when "compiling" the semantics of the insn.
   semantic-compile will call rtx-traverse which will use the mode of the
   result as the default mode for operand0.  subword is not a normal rtx;
   the mode of operand0 is its own mode, not the mode of the result of
   the rtx.

I tested your patch and it works as expected.  It also fixes another problem
I was experiencing (and I think I posted about): converting modes from (say)
SF to (say) SI was not working, despite being documented as useful in the
manual.

By all means, feel free to check in your patch.

Thanks, Ben