Hi,
On 29 August 2017 at 04:54, Masaki Arai masaki.arai@linaro.org wrote:
Hi,
Thank you very much for your quick check and reply.
Kugan Vivekanandarajah kugan.vivekanandarajah@linaro.org writes:
I looked into the structure, adding this field is not going to make the
s=
tructure bigger for either ILP32 or LP64 targets. If you want, you use
bit=
-fields; there is one bool already there which means you can fit 8 bits
in =
the same area as currently taken up by that one.
Yes. I should have checked the mem_attrs structure. This does have at least a byte left unlike some other tightly packed structures (gimple and some tree structures in gcc).
Even though memory usage does not increase, I understand the policy of wanting to make the data structure simple.
Another way to implement this feature is to use the `addrspace' field in `struct mem_attrs' without adding any fields. I think that this implementation may be more decent. However, since this field holds information specific to the target machine, changing this will affect many files.
I think your current approach is reasonable. It is better to discuss your alternate approach upstream. I would suggest you post your patch upstream and initiate a discussion there. Please refer to https://gcc.gnu.org/contribute.html (submitting patches part) if you already haven't.
Alternatively, we maybe able to get this info from dwarf info when we
co= mpile with -g ?
I doubt you can. He wants to know if an instruction is a spill
location.=
The location of a variable might be recorded in -g (if it was an user
var=
iable) but not that does present the data for all temps being spilled.
I think the patch is actually a good one in general just needs some
clean=
up.
I was not thinking about implementation using DWARF. About 2013, I have created a tool to extract information from DWARF data in binary files generated by GCC. At that time, there were some shortages in the DWARF information, and as a result, it did not go very well.
I am not an expert in DWARF but I can understand that this can be a problem.
Thanks, Kugan
Best regards,
Masaki Arai _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain