On 10/1/2010 9:40 PM, Suneel Jain wrote: > The original design for targ_info was intended to allow quick changes > to the machine description without needing to rebuild the compiler. > This allowed for quick experiments in generating code for various > scenarios during the design of new processors. > > I don't know how much any of the current users of Open64 utilize this > ability. Does Tensilica take advantage of this capability to generate > a new compiler for a reconfigured processor ? > Tensilica builds the target info on the fly from tables which are in target specific shared libraries. So we are not directly using the old setup to switch on target info shared libraries but we do use different shared libraries to construct target info for different targets. Machines nowadays are fast enough that rebuilding the target info is not too bad.
Ding-Kai > One big problem 15 years ago was that compiling/linking the whole backend > took a long time. By comparison creating a new proc_xxx.so was quick. > This difference is not very significant anymore and not a compelling reason > to stick with the current architecture. > > I do agree with David that folding multiple scheduling models into the > backend binary simplifies the build and installation of Open64. There > are some platforms that don't support shared libraries or implement > shared libs in a different enough way to make porting messy. > > So, I personally am not opposed to this change. It would be good > to get additional feedback from others who have ported Open64 to > different platforms. > > - Suneel > > > On Fri, Oct 1, 2010 at 4:38 PM, Sun Chan<sun.c...@gmail.com> wrote: > >> I'd like to see more detailed reasons why current model does not >> easily support change of target (micro-arch). The reason why that was >> implemented as dso is precisely for that reason. And we have (back at >> SGI) done multiple generations of the same family (past, present and >> future) by stating processor_id in command line and have the compiler >> dynamically link in the right model. Of course, that was done for >> IRIX. >> Your suggestion implies having a union of all generations of the same >> family (otherwise, you will need rebuild of the compiler). I am not >> against your proposal, but your claim for what current does not >> support doesn't match what original design goal and my own >> recollection. >> Suneel and Mike might be able to give more details and opinion. >> Sun >> >> On Sat, Oct 2, 2010 at 7:26 AM, David Coakley<dcoak...@gmail.com> wrote: >> >>> Hi all, >>> >>> I am submitting a proposal to eliminate the scheduling info DSOs and >>> instead incorporate that info directly into the backend. The primary >>> motivation is portability. The proposal is described in more detail >>> in the attachment "no_si_dso.txt". >>> >>> Before making these changes, I thought it was a good idea to clean up >>> the compilation warnings in targ_info and its generated code, and to >>> fix some known portability problems (bugs 622, 624, 658). The patch >>> "ti_cleanup.diff" is a code cleanup patch that accomplishes those >>> goals without making any changes in the current behavior. The details >>> are in the tentative log message, "log_msg.txt". >>> >>> Could a gatekeeper please review the patch? >>> >>> I have prototyped the proposed targ_info DSO changes for x8864. I >>> would like feedback from some of the gatekeepers and especially the >>> maintainers for other targets -- I will need your help since the >>> changes affect all targets. Thanks, >>> >>> -David Coakley / AMD Open Source Compiler Engineering >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing. >>> http://p.sf.net/sfu/novell-sfdev2dev >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >>> >>> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel >> >> > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > . > > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
