This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Make m32c build, fix PSImode truncation
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: bernds at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 30 Apr 2013 08:24:03 +0100
- Subject: Re: Make m32c build, fix PSImode truncation
- References: <517A8974 dot 7000202 at codesourcery dot com> <87a9okicyo dot fsf at talisman dot default> <517E42C4 dot 9020407 at codesourcery dot com> <87y5c1plr3 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <201304291833 dot r3TIXtM6031696 at greed dot delorie dot com>
DJ Delorie <dj@redhat.com> writes:
>> Sorry for missing the truncation patterns, I should have grepped
>> more than m32c.md. They look a lot like normal moves though. Is
>> truncation really not a noop, or are the patterns there to work
>> around something (probably this :-))?
>
> Not sure which pattern you're talking about, but in general, the
> m32c's registers are either 16-bit or 24-bit. You can move a pair of
> 16-bit registers into a 24-bit register and it truncates as part of
> the move, likewise from 32-bit memory to 24-bit reg. Note that moves
> to other 32-bit destinations do *not* truncate, nor can 24-bit
> registers hold 32-bit values (duh). The 24-bit registers may also
> hold a 16-bit value.
The pattern in this case was:
(define_insn "truncsipsi2_24"
[(set (match_operand:PSI 0 "m32c_nonimmediate_operand" "=RsiSd*Rmm,Raa,!Rcl,RsiSd*Rmm")
(truncate:PSI (match_operand:SI 1 "m32c_nonimmediate_operand" "0,RsiSd*Rmm,RsiSd*Rmm,!Rcl")))]
"TARGET_A24"
"@
; no-op trunc si %1 to psi %0
mov.l\t%1,%0
ldc\t%1,%0
stc\t%1,%0"
[(set_attr "flags" "n,sz,n,n")]
)
(the ICE I mentioned was on -mcpu=m32cm, forgot to mention that sorry).
It looked like alternatives 0 and 1 were really moves, with alternative
0 being a no-op move.
The question was really whether:
(set (reg:PSI foo) (truncate:PSI (reg:SI bar)))
and:
(set (reg:PSI foo) (subreg:PSI (reg:SI bar) 0))
are fundamentally different on this target. In other words,
does m32c really want to set TRULY_NOOP_TRUNCATION to false for
SImode->PSImode truncations, but can't because the interface is broken
for partial ints? It looked to me like the answer was "no" in both cases:
truncation from SImode to PSImode seems to work just like a lowpart subreg
on this target.
The corresponding move pattern seems to be:
(define_insn "movpsi_op"
[(set (match_operand:PSI 0 "m32c_nonimmediate_operand"
"=Raa, SdRmmRpi, Rcl, RpiSd*Rmm, <, <, Rcl, RpiRaa*Rmm")
(match_operand:PSI 1 "m32c_any_operand"
"sIU3, iSdRmmRpi, iRpiSd*Rmm, Rcl, Rpi*Rmm, Rcl, >, >"))]
"TARGET_A24 && m32c_mov_ok (operands, PSImode)"
"@
mov.l:s\t%1,%0
mov.l\t%1,%0
ldc\t%1,%0
stc\t%1,%0
push.l\t%1
pushc\t%1
popc\t%0
#"
[(set_attr "flags" "sz,sz,n,n,n,n,n,*")]
)
and AIUI alternative 1 in the truncsipsi2_24 pattern is basically acting
like alternative 1 in movpsi_op.
If that's right, what do you think of the patch I posted yesterday?
Thanks,
Richard