Hi, On 29 August 2017 at 04:54, Masaki Arai <masaki.a...@linaro.org> wrote: > Hi, > > Thank you very much for your quick check and reply. > > Kugan Vivekanandarajah <kugan.vivekanandara...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
