Steven Bosscher schrieb:
Hi Johann,You say you have: src= (mem/v/c:HI (post_inc:HI (const:HI (plus:HI (symbol_ref:HI ("V") [flags 0x402] <var_decl 0xb7ce8720 V>) (const_int 1 [0x1])))) [3 V.i2+0 S2 A8 AS2]) while in cprop.c. That is your bug. Where does the post_inc come from? They're not supposed to exist at
The POST_INC are generated at expand time. It's for an address space where the only reasonable addressing mode is POST_INC. Indirect addressing turned out to cause extreme code bloat, see PR rtl-optimization/52543 and http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
this point in the compilation pipeline. Most passes (cprop, gcse hoist/pre, cse, fwprop, ...) don't handle auto-increment and auto-decrement operations like this, because they're only supposed to exist after pass_inc_dec (with the exception of push to / pop from the stack). Ciao! Steven
Thanks for your information. To overcome these shortcomings/implications I moved completely away from MEM to represent loads from the address spaces in question. This is possible because read is from rodata like memory that won't change, i.e. reading from the same address will yield the same result. Moreover, pre-/post-modify addressing optimization is very poor: Even for code like var = *p++; var = *p++; var = *p++; ... I see that GCC loads the address to some oather register instead of using post-increment. This means there is absolutely no advantage with using the reload machinery. Moreover, while working with the address spaces to represent segmented memory, I observed that GCC is not yet ready for these kind of thing, in particular register allocator cannot handle/reload the addresses. This means that GCC is not suitable to be used for architectures with segmented memory layouts like Microchip's PIC or Infineon's C16x even though there is named address space support now. Johann
