On 11/22/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > I've been quietly watching the conversation, largely as an interested > user as opposed to a GCC developer. One of my concerns lies with: I have worked on some toy front ends, so I think that I am a kind of a user also :)
> GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL > > That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here -- > perhaps simple one, perhaps not. The line is very straight, but adding > two more segments make me wonder if we're complicating the plumbing. > > How will this effect compiler speed? It is hoped that optimizing in LLVM will be faster than optimizing in GIMPLE. So optimized builds are likely to be faster. > How will debugging information flow accurately through the process? I think that this is an open issue. The major technical one. > And will we be making it even more difficult to isolate problems? Not in the LLVM part. If the conversion is turned on all the time it will receive a lot of testing. And LLVM is simpler and has some nice tools to help in bug hunting. > Already, we have people who understand frontends, and others who know > GIMPLE initimately, and still overs who focus on RTL generation. Is > adding two additional passes going to further fragment expertise? Tha algorithms are going to be more or less the same. The data structures are going to be different. There will be a need the learn a new API, but this is true for any proposal that involves changing the internal representation. > I understand Rafael's comment, as quoted here: > > > In a first stage nothing will be done with the LLVM representation > > except convert it back to GIMPLE. This will make sure that all > > necessary information (including debug) can pass through the LLVM. The > > conversion will also receive very good testing with this. > > Does this mean that the "LLVM pass" will initially invoked only via an > option, and that a normal compile will continue the current path until > LLVM is fully tested and accepted? I was hopping that this would be done only to have a fast track for adding LLVM. After that, the current path would be ported as fast as possible. Others have expressed concerns about needing a c++ compiler to bootstrap. It may be possible then to maintain an option of short cutting the GIMPLE -> LLVM -> GIMPLE conversion so that stage1 can be build with a C compiler. > Just questions; if they are stupid, please be gentle. ;) > > -- > Scott Robert Ladd <[EMAIL PROTECTED]> > Coyote Gulch Productions > http://www.coyotegulch.com > Rafael