This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thoughts on LLVM and LTO


On 11/22/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> 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 <scott.ladd@coyotegulch.com>
> Coyote Gulch Productions
> http://www.coyotegulch.com
>
Rafael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]