This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

YAMP: ivopts vs sizetype


(yet another m32c-related problem)

Something in ivopts is converting this:

  ap.1_5 = ap_38 + 2;
  ap.2_6 = (struct tiny *) ap_38;
  SR.8_15 = ap.2_6->c;

to this:

  ap.1_5 = ap_38 + 2;
  SR.8_15 = MEM[base: ap.1_5, offset: 65534];

Now, recall that for -mcpu=m32c size_t is 16 bits but pointers are 24
bits.  The above SHOULD have resulted in this:

	mov.b	-2[a0], r0

which I would have converted to this:

	mov.b	16777214[a0], r0

but instead I get this (and lots of testsuite errors):

	mov.b	65536[a0], r0

So, there are two problems here:

First, something in ivopts is using sizetype to manipulate pointers,
which doesn't work.  I've seen plenty of cases where sizetype is used
where the original pointer type could have been used (or even
HOST_WIDE_INT) but couldn't track down the specific case that's the
culprit.  Help?

Second, this type of addressing is expensive on the m32c
(displacements are always unsigned).  It would have been far better to
use ap_38 and not had a displacement (or had a small positive one).
Is there a way to tell SSA (or gcc in general) that negative
displacements are expensive?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]