This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Thoughts on LLVM and LTO
I've been quietly watching the conversation, largely as an interested
user as opposed to a GCC developer. One of my concerns lies with:
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?
How will debugging information flow accurately through the process?
And will we be making it even more difficult to isolate problems?
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?
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?
Just questions; if they are stupid, please be gentle. ;)
--
Scott Robert Ladd <scott.ladd@coyotegulch.com>
Coyote Gulch Productions
http://www.coyotegulch.com