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 "t
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 ther
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
Steven Bosscher <[EMAIL PROTECTED]> writes:
[...]
| I'd be surprised if there a compiler exists that runs optimizations
| on EDG's C++ specific representation.
CFront was very good at implementing optimizations "native" compilers
could not match at the time (or with 2 years lag). KCC did a grea
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
> I don't see anything about Tree that I find inherently awful; in fact,
> it looks very much like what I see in other front ends. There are
> aspects I dislike (overuse of pointers, lack of type-safety, unncessary
> copies of types), but I couldn't possibly justify changing the C++
> front-end, f
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 a
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
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
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
Ian Lance Taylor wrote:
> In short, while this is an important issue, I don't see it as strongly
> favoring either side. What it means, essentially, is that LTO is not
> quite as much work as it might otherwise seem to be, because we are
> going to do some of the work anyhow. So when considering
On Tuesday 06 December 2005 00:23, Jim Blandy wrote:
> Debug information describes two things: (...snip...)
> Keeping the two representations separate (which I could easily
> see being beneficial for optimization) shifts that burden onto some
> new party which isn't being discussed, and which will
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
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
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 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
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 Tr
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 are
18 matches
Mail list logo
