Mathieu Lacage wrote:
A path where different solutions for different problems are evolved
independently and then merged where it makes sense seems better to me
than a path where a single solution to two different problems is
attempted from the start.
Which is thus why I think that there
Mark Mitchell [EMAIL PROTECTED] writes:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
at the source-level version of Tree
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
at the source-level
Steven Bosscher [EMAIL PROTECTED] writes:
| On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
| There is one advantage I see in the LTO design over LLVM's design. In
| particular, the LTO proposal envisions a file format that is roughly at
| the level of GIMPLE. Such a file format
On Dec 5, 2005, at 11:48 AM, Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's
design. In
particular, the LTO proposal envisions a file format that is
roughly at
the level of GIMPLE. Such a file format
On 12/5/05, Chris Lattner [EMAIL PROTECTED] wrote:
That said, having a good representation for source-level exporting is
clearly useful. To be perfectly clear, I am not against a source-
level form, I am just saying that it should be *different* than the
one used for optimization.
Debug
Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level. The two
have very different goals and uses, and trying to merge them into one
On Dec 5, 2005, at 5:27 PM, Mark Mitchell wrote:
Steven Bosscher wrote:
IMVHO dumping for export and front-end tools and for the optimizers
should not be coupled like this. Iff we decide to dump trees, then I
would hope the dumper would dump GIMPLE only, not the full front end
and middle-end
On Dec 5, 2005, at 5:43 PM, Mark Mitchell wrote:
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level.
The two
have very different goals
Chris Lattner wrote:
[Up-front apology: If this thread continues, I may not be able to reply
for several days, as I'll be travelling. I know it's not good form to
start a discussion and then skip out just when it gets interesting, and
I apologize in advance. If I'd been thinking better, I would
Steven Bosscher wrote:
What makes EDG so great is that it represents C++ far closer to the
actual source code than G++ does.
I know the EDG front-end very well; I first worked with it in 1994, and
I have great respect for both the EDG code and the EDG people.
I disagree with your use of far
hi mark,
On Mon, 2005-12-05 at 21:33 -0800, Mark Mitchell wrote:
I'm not saying that having two different formats is necessarily a bad
thing (we've already got Tree and RTL, so we're really talking about two
levels or three), or that switching to LLVM is a bad idea, but I don't
think there's
I've been watching the LLVM/LTO discussion with interest.
I'm learning that I need to express myself carefully, because people
read a lot into what I say, so I've been watching, and talking with lots
of people, but not commenting. But, I've gotten a couple of emails
asking me what my thoughts
14 matches
Mail list logo