Sun and others, Thanks for the feedback and insight into the original design.
You are right -- it should be possible to support on-the-fly switching with the current code. I was thinking of a future scenario where we implement support for the GNU "target" attribute. It operates at the function level and a DSO load/unload seemed like a heavyweight operation to do for compilation of (potentially) a single function. It sounds like there is support for the changes even if we disregard this point. -David Coakley / AMD Open Source Compiler Engineering On Fri, Oct 1, 2010 at 9:40 PM, Suneel Jain <suneel.j...@gmail.com> 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 ? > > 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 >> > ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
