Re: error linking lto1 for target avr
Ian Lance Taylor wrote: > Georg-Johann Lay writes: >> Ian Lance Taylor wrote: >>> Georg-Johann Lay writes: >>> 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. So if a frontend can define address spaces and it is a generic feature, the question is how to get the name of an address space in a generic, language independent way. So the question breaks down to: How do you get the name of an address space in a generic way, i.e. what is the generic equivalent to c_addr_space_name? Should be something like const char* ADDR_SPACE_NAME (addr_space_t); but the only thing I could find in the compiler was the c_addr_space_name and nothing else. Also I observed that RTL dumps just print AS3 to dump an address space. >From where would an RTL dumper get the address spaces' name to print the address space information in an eye-friendly way, e.g. AS3 (__pgm2) instead of just AS3? > 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. It's clear to me that such a fix is not a big affair and straight forward. However, running into an error is always a good opportunity to get better understand of things and learn something. Unfortunately, people don't like errors. Johann > Ian
RE: A case exposing code sink issue
Hi, On Mon, 28 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? Yes, the number of iterations of the i loop simply is too difficult for our loop iteration calculator to comprehend: for (i=k; i<500; i+=k) iterates for roundup((500-k)/k) time. In particular if the step is non-constant our nr-of-iteration calculator gives up. > I thought it was still an aliasing problem. No. All accesses are resolved to final objects (i.e. no pointers), and hence can be trivially disambiguated. Ciao, Michael.
Re: error linking lto1 for target avr
Georg-Johann Lay writes: > So if a frontend can define address spaces and it is a generic feature, the > question is how to get the name of an address space in a generic, language > independent way. We could decide that all frontends that use address spaces must define a printable name for each address space. That would mean changing the middle-end address space interface to give a name to each address space. The current middle-end address space interface does not require that address spaces have a name. I was not involved in the addition of address spaces to gcc, and I don't know why they followed the path they did. Ian
