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.sandif...@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
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
