H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod <tbela...@arm.com> wrote:
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin <kirill.yuk...@gmail.com>
wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mode1 to mode2 for given
In many places, the macro is used with the known offset.
I have a follow up patch which improves x86 code generation,
in cases like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
What is it that subreg_get_info () can't resolve that
CANNOT_CHANGE_MODE_CLASS with an offset can?
We have
int
simplify_subreg_regno (unsigned int xregno, enum machine_mode xmode,
unsigned int offset, enum machine_mode ymode)
{
struct subreg_info info;
unsigned int yregno;
#ifdef CANNOT_CHANGE_MODE_CLASS
/* Give the backend a chance to disallow the mode change. */
if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
&& GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
&& REG_CANNOT_CHANGE_MODE_P (xregno, xmode, ymode)
/* We can use mode change in LRA for some transformations. */
&& ! lra_in_progress)
return -1;
#endif
CANNOT_CHANGE_MODE_CLASS is checked before subreg_get_info is
called. When REG_CANNOT_CHANGE_MODE_P returns false,
there is nothing subreg_get_info can do.
So, if (subreg:DI (match_operand:V4SF 1 "register_operand" "x,x") 0) is a valid
subreg, why not allow it in CANNOT_CHANGE_MODE_CLASS (like in Kirill's patch
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00987.html) and resolve the actual
register later in subreg_get_info ()?
In general, as I understand it, CANNOT_CHANGE_MODE_CLASS doesn't need an offset
because it only checks for validity of a mode-change in a regclass from the
point of view of bit-correct-representation (eg. a register when subreg'ed still
has the same order of bits) - the actual register reference is done elsewhere
using the offset.
Thanks,
Tejas.
