m32c has no problem loading a 24-bit register from a 32-bit memory
location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
m32c doesn't use any of the single-character constraints, as they're
too general to pretty much
Quoting DJ Delorie d...@redhat.com:
m32c has no problem loading a 24-bit register from a 32-bit memory
location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
m32c doesn't use any of the single-character constraints, as
I suggest making reload reload the PSImode subreg instead, and
make the m32c machine description provide for a tertiary
reload so that the value can be loaded truncated.
Don't know how to set up a tertiary reload (it's not documented
anywhere).
Is this the type of patch you're thining
Quoting DJ Delorie d...@redhat.com:
I suggest making reload reload the PSImode subreg instead, and
make the m32c machine description provide for a tertiary
reload so that the value can be loaded truncated.
/
Don't know how to set up a tertiary reload (it's not documented
anywhere).
It's
From looking at the m32c machine description I got the impression
that you can't directly load A_REGS in PSImode from a PSImode subreg
of a SImode memory location, but maybe I was mistaken.
The big problem with m32c (--mcpu=m32c) is that pointers are 24 bits,
which doesn't correspond to any
Quoting DJ Delorie d...@redhat.com:
m32c has no problem loading a 24-bit register from a 32-bit memory
location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
It had crossed my mind that you could use
Any ideas?
This:
Reload 0: reload_in (SI) = (reg/f:SI 25 [ __i1$_M_current ])
A_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:SI 25 [ __i1$_M_current ])
cannot be satisfied because there is no A_REGS register
acceptable in SImode.
I suggest making reload
This is typical of the types of failures m32c got before IRA, too. I
had a good build on Feb 19th, but if I try to reproduce it, it fails
too.
Fails with -O2, works with -Os. Note: you might need -fno-ivopts to
get around the recent m32c/IV problems.
Any ideas? Any thoughts on why gcc has so
