Georg-Johann Lay <a...@gjlay.de> writes: > Ian Lance Taylor wrote: > >> Georg-Johann Lay writes: >> >>> Suppose avr.c:avr_out_lpm which is used to print insns in final, >>> e.g. ADJUST_INSN_LENGTH. >>> >>> Should avr_out_lpm be moved to avr-c.c? And avr-c.c include all the >>> rtl.h, tree.h, output.h etc. which is also needed by the functions >>> that like to use c_addr_space_name? >> >> It's fine for avr-c.c to include rtl.h, tree.h, etc. (though including >> tree.h is unusual). It's fine for avr-c.c to call functions in avr.c. > > I need it the other way round: With a wrapper for c_addr_space_name located in > avr-c.c that wrapper (or any other code moved to avr-c.c) needs to be called > from avr.c. Is that ok? If the answer is "yes": I don't quite understand why > that works and at what stage the otherwise missing function/object is dragged > in. If the answer is "no": This means I have to copy-paste the code from > c-common to avr.c? If such hack is actually needed, there must be a design > flaw > somewhere.
The problem is straightforward if you stop and think about it. The code in c-family is only available in the C and C++ frontends (and Objective C and Objective C++). When using LTO, neither the C nor the C++ frontend is linked into the binary. When using LTO, you can not call a function which only exists in the C or C++ frontend. The point of avr-c.c is for it to provide functions which are only used with the C and C++ frontends. You can't call from avr.c to avr-c.c. That would just be the same problem in a different form. Copying the function c_addr_space_name to avr.c won't work either. That function needs to know information that only exists in the C and C++ frontends. >> The point is that functions that are C/C++ specific need to not be in >> avr.c, because they will break for languages other than C/C++. In this >> terminology, LTO counts as a language. >> >>> Is is legitimate to use MEM_ADDR_SPACE in avr.c? >> >> Yes. > > Again I don't understand. MEM_ADDR_SPACE does not make sense when compiling > Ada, say. I'd guess XXX_ADDR_SPACE are just accessors for fields in tree or > rtx > that are reserved by the C front end. How do I know that the Ada front end > does not reserve these bits for different purpose so that using the accessors > get funny results? MEM_ADDR_SPACE is defined generically. You can see it in rtl.h. Any frontend can create and use address spaces. > Moreover, I don't get the difference between c_addr_space_name on the one side > and MEM_ADDR_SPACE, TYPE_ADDR_SPACE, ADDR_SPACE_GENERIC and addr_space_t on > the > other side. I mean on the conceptual level, not on the technical > (macro/function/typedef) level. c_addr_space_name corresponds to c_register_addr_space. This is distinct from addr_space_t and friends. Any frontend can define values for addr_space_t. The C/C++ frontends happen to permit the backend to define such values via c_register_addr_space. > They all make sense in C only, not even in C++ because named addresses are not > available in C++. That is not a fundamental limitation, just a statement about what the various frontends currently implement. The current code in avr.c is only calling c_addr_space_name to get the name for an addr_space_t. You already have a mapping from address space names to addr_space_t values in avr_register_target_pragmas in avr-c.c. Just move that into a table in avr.c and use that table rather than c_addr_space_name. Ian
