Target specific memory attributes from RTL
Reference(s): 1. Mail: James E Wilson <[EMAIL PROTECTED]>, "Re: How to get m/c dependent attributes from RTL (expressions, not a variable)?", 10-Feb-2005. 2. Mail: James E Wilson <[EMAIL PROTECTED]>, "Re: How to get m/c dependent attributes from RTL (expressions, not a variable)?", 12-Feb-2005. Hi all, 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. Thanks in advance, Balaji Sivan
Re: Target specific memory attributes from RTL
_On 11-Mar-2005 02:48, James E Wilson san wrote_: Note that in this case finding the target means indirecting through a memory address, and hence we would have to track the attributes of all memory locations which is a difficult and perhaps unsolvable problem. As I said before, I think what you are trying to do is fundamentally flawed. If you need attributes, you use them when generating RTL, not when optimizing or emitting RTL. Is expression evaluation (expr.c, expand_expr_real) converting tree into RTL, the right place to extend GCC as required? I am planning to extend memory attributes (rtl.h, mem_attrs) with one more tree node to have type declaration of this memory. Please correct me if i am wrong and give me the areas to be handled carefully while doing this. Thanks in advance, Balaji Sivan
Problem with Delayed Branch Scheduling
Hi everybody, I have a problem with delayed branch scheduling. Problem in a DSP porting which has VLIW instructions and delayed branches. While scheduling delayed branches, GCC (3.4.3) schedules an instruction which is a part of a VLIW instruction. Is this the problem of the following define_delay description? (define_delay (eq_attr "type" "jump") [(eq_attr "type" "!jump") (nil) (nil) (eq_attr "type" "!jump") (nil) (nil)]) Thanks in advance, Balaji Sivan
Re: Problem with Delayed Branch Scheduling
_On 04-Jul-2005 15:31, Steven Bosscher san wrote_: Add an attribute to those instructions that cannot be in delay slots, and change this define_delay to disallow instructions with that attr? Any instruction other than jump can be placed in the delay slot. I hope "!jump" can fulfill this requirement. I don't have any idea to identify a part of a VLIW instruction and disallow it delay slot. I only know that TImode of insn signifies a new cycle start. please hlep me by giving some pointers.
Re: Problem with Delayed Branch Scheduling
_On 05-Jul-2005 00:14, Ian Lance Taylor san wrote_: Steven Bosscher <[EMAIL PROTECTED]> writes: So you have a few instructions bundled into a VLIW instruction, and one of the instructions in the bundle is moved into the delay slot, thus breaking your VLIW bundle. Right? I think there are two natural approaches. 1) Do the VLIW bundling after delayed branch scheduling. The way to do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE. The FRV backend does this. I've done this successfully in the past. I think this is a good workaround but nullifying the possibility of having a VLIW bundled instruction in a branch delay slot. 2) When you do the VLIW bundling, put the instructions into a PARALLEL. I think this is the right solution which rectifies the problems. Please provide the pointer to where it has to be done. In general the gcc scheduler does not handle VLIW scheduling very well, and it needs a fair amount of target specific help. I dont know the list of known requirements (help), but from my side, currently insns are marked by TImode to signify the start of a VLIW bundle but some assemblers may require to signify the end of a VLIW bundle. There is no provision for that. Currently i have hacked GCC to meet this requirement.
Re: How to get m/c dependent attributes from RTL (expressions, not a variable)?
_On 10-Feb-2005 08:36, James E Wilson san wrote_: Balaji S wrote: I have introduced m/c dependent attributes and handling it's semantics via the attribute's handler. And i want to use these attributes during assembly printing from RTL. How to get these attributes? This isn't how attributes are normally used. They are normally used for changing how variables/functions are defined, and how we emit RTL to access them. There is no guarantee that tree info for variable declarations will still be accessible when converting RTL insns to assembly. There is also the problem that the optimizer can do various things to memory load/store instructions. There may not be a one-to-one correspondence between loads and variables, and hence no guarantee that you have a usable mem_expr. If you need something special here, it really needs to be done when the RTL is emitted, not when the assembly is emitted. Yes. I agree on your point that attributes may not be valid after optimizations. Can you please tell me how to get these attributes while emitting RTL? My requirement is, need the newly introduced attributes while doing memory access. Thanks in advance, Balaji Sivan
