Re: error linking lto1 for target avr
Georg-Johann Lay 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
RE: A case exposing code sink issue
> -Original Message- > From: Michael Matz [mailto:m...@suse.de] > Sent: Friday, November 25, 2011 11:23 PM > To: Jiangning Liu > Cc: gcc@gcc.gnu.org > Subject: RE: A case exposing code sink issue > > Hi, > > On Thu, 24 Nov 2011, Jiangning Liu wrote: > > > One more question... > > > > Can " i = i.6_18;" be sinked out of loop, because it doesn't have > memory > > dependence with others? > > With current trunk the stores to i, a_p, b_p and k are sunken after the > loop. (There are no aliasing problems because the decls can't > conflict). > > What isn't sunken is the calculation of the &a[D.2248_7] expression. > First, the number of iterations of the inner loop can't be determined > by > current code (replacing i+=k with e.g. i++ could be handled for > instance). Hi Michael, Do you know what the essential problem is in the case of loop iteration uncertainty? I thought it was still an aliasing problem. Thanks, -Jiangning > Then this code could be handled by final value replacement, but isn't > because interpret_rhs_expr doesn't deal with ADDR_EXPR of ARRAY_REFs. > > > Ciao, > Michael.
Re: error linking lto1 for target avr
> Again I don't understand. MEM_ADDR_SPACE does not make sense when > compiling Ada, say. Why? > 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? These are macros of the middle-end, front-ends aren't allowed to overload them. > 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 is C-specific whereas the others are generic. -- Eric Botcazou
Re: error linking lto1 for target avr
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 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? 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. They all make sense in C only, not even in C++ because named addresses are not available in C++. >> Is is legitimate to use TYPE_ADDR_SPACE in avr.c? > > Yes. > >> Must all this put into avr-c.c? > > Not for that reason, no. > > To a first approximation, anything that refers to something declared in > c-common.h must be in avr-c.c, not in avr.c. > > Ian Johann
Re: error linking lto1 for target avr
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 moced 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. 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. > Is is legitimate to use TYPE_ADDR_SPACE in avr.c? Yes. > Must all this put into avr-c.c? Not for that reason, no. To a first approximation, anything that refers to something declared in c-common.h must be in avr-c.c, not in avr.c. Ian
Re: error linking lto1 for target avr
Steven Bosscher schrieb: In avr.c there is: ... #include "c-family/c-common.h" ... That is the problem: avr.c should be language independent. Here you are trying to link code calling C-family functions in a non-C language (lto1 is just another front end for gcc, just like cc1/cc1plus/etc...). You should use extra target files for language specific target code. Plenty examples in config/*/*-c.* ... Ciao! Steven I don't quite get it. Could you be more specific? Suppose avr.c:avr_out_lpm which is used to print insns in final, e.g. ADJUST_INSN_LENGTH. Should avr_out_lpm be moced 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? If a function is mode to avr-c.c and uses c_addr_space_name how does that avoid liker error? Either it gets error for c_addr_space_name because it is still missing and needed, or it gets linker error for the outsourced function like avr_out_lpm. Anything that uses address space stuff is language dependent. Thus: Is is legitimate to use MEM_ADDR_SPACE in avr.c? Is is legitimate to use TYPE_ADDR_SPACE in avr.c? Must all this put into avr-c.c? Johann
