On Fri, May 23, 2008 at 5:07 AM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > (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
Uh, so sizetype is 32bit but pointer displacements are 24bit? :( > 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? Yeah, the affine combination code still has its problems with the introduction of POINTER_PLUS - we also still get MEM_REFs with integers as base pointer. I hope at some point to have enough time to dig into this ... > 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? So negative displacements will be 24bit displacements (expensive) and small positive displacements will fit in 16bit (or even 8bit) displacements? I don't think you can tell that, but maybe look into tree-ssa-address.c where it asks the target for costs via building some rtx-en. Richard.
