Hi,
Thank you very much, everyone, who gave me useful advice. I might conclude that extension of GCC for HCQC is completely unnecessary.
Richard Sandiford richard.sandiford@linaro.org writes:
An alternative to adding a new flag might be to check:
MEM_EXPR (mem) == get_spill_slot_decl (false)
I think that this method is far better than introducing the flag `for_spill_p'! For this approach, the additional code can only be the following 6 lines in final.c.
+ + if (MEM_P (op) && MEM_EXPR (op) && MEM_EXPR (op) == get_spill_slot_decl (false)) + { + HOST_WIDE_INT size = MEM_SIZE (op); + fprintf (asm_out_file, " (" HOST_WIDE_INT_PRINT_DEC "-byte spill slot)", size); + }
I implemented this, and it seems to work fine both on AArch64
ldr x0, [x29, 192] // tmp1241, %sfp (8-byte spill slot) str w0, [x29, 204] // ivtmp_805, %sfp (4-byte spill slot)
and on x86_64
movsd 8(%rsp), %xmm1 # %sfp (8-byte spill slot), prephitmp_811 movsd %xmm0, 16(%rsp) #, %sfp (8-byte spill slot)
The important point here is that "spill slot" is always displayed with "%sfp" attached. This is because the object returned by `get_spill_slot_decl' always points to the following decl tree `d'.
d = build_decl (DECL_SOURCE_LOCATION (current_function_decl), VAR_DECL, get_identifier ("%sfp"), void_type_node);
This means that "%sfp" is "spill slot" on all target machines. I checked the source code of GCC, and it seems that only this part of code uses "%sfp". This "%sfp" does not express data size, but HCQC can get data size information from assembly codes in the same line with "%sfp". Therefore, the conclusion is that it is enough for HCQC to detect "%sfp" without any extension of GCC.
But this would bake in the assumption that everything we want to mark as a spill slot will use set_mem_attrs_for_spill, whereas the flag would allow other MEMs to be marked as spill slots too.
I guess that the effect of the flag can also be realized with the following code:
MEM_EXPR (mem) = get_spill_slot_decl (false);
instead of
MEM_ATTRS (mem).for_spill_p = true;
The only case where `for_spill_p' seems to be useful is where some optimizations combine a memory area V on the stack for a local variable and a memory area S for the spill code together and make it the V only using the result of live range analysis for both memory areas. In that case, the code
MEM_ATTRS (V).for_spill_p = true;
holds the original memory expression with this additional flag. However, it may be a matter of opinion whether this memory region should be considered spill areas or not.
Best regards, -- -------------------------------------- Masaki Arai