(I and likely others would also be grateful for further insight) As to enable the efficient use of non-Von-Newman memory architectures typical of many vector/signal processors, and smaller microcontrollers; it seems imperative that target specific attributes assigned to an object remain correct throughout the compilation process to enable the backend to properly identify which memory space a referenced object is allocated within, so that it may be correspondingly accessed appropriately.
But as you have observed, and Jim Wilson has noted, it seems that object attributes may either be lost, or not fully accessible beyond one level of indirection by the time rtl/template matching begins. This would would seem to seriously prohibit GCC being able to reliably track an object's allocated location through the use of target specific attributes? Does anyone have any further insight with respect to this potential problem? Referencing your and Jim's earlier messages: http://gcc.gnu.org/ml/gcc/2005-02/msg00456.html > Balaji S writes: > As suggested in references, i'm able to get the target specific attributes > from RTL in the following cases: > 1. Through SYMBOL_REF_FLAGS and if it is a SYMBOL_REF RTL (symbol_ref: ...), > direct variable > 2. Through MEM_EXPR of MEM if its operand is not a SYMBOL_REF and a REG > (mem:HI (reg:...)), indirect variable access > 3. Through REG_EXPR of REG of a MEM and memory access is a first level pointer > reference (mem:HI (reg:...)), indirect memory access > > But, i'm not able to access target specific attribute from second level of > indirection onwards. > > For example, > int **gpi ; > > variable_decl of 'gpi' is available during access of 'gpi' and '*gpi' and not > during '**gpi'. > > I have looked at existing ports for similar implementation of memory > attributes but failed to find one. > > Please point me a good resource for handling memory attributes.
