On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:
> From what I've read and gathered from David over a period of some
> conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0
> was - they have a well defined AST that is capable of representing
> everything you'd expect in a typical C-family language, with a
> backdoor to lower level register/assembly representations for
> target-specific implementations.

If you are referring to LLVM here: Yes and no.

It's true that the LLVM IR is mostly target-independent (except for data type sizes and so on) with a number of backdoors in the form of inline assembly, special intrinsics and so on.

But at the same time, the LLVM IR is also of a very different quality than GCC GENERIC, being strictly in SSA form. I have not looked into the current GCC architecture in any detail, but I'd guess that LLVM itself starts approximately at the point where the middle-end does in GCC.

Clang itself is obviously on a higher layer, but unlike GENERIC, its data structures are not designed to be reused for non-C-family languages. So, the questions of whether its AST can represent every concept from another language or if it needs contains backdoors to a lower level are somewhat moot.

David

On 28 October 2013 21:24, David Nadlinger <code@klickverbot.at> wrote:
> On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:
>>
>> From what I've read and gathered from David over a period of some conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations.
>
>
> If you are referring to LLVM here: Yes and no.
>
> It's true that the LLVM IR is mostly target-independent (except for data type sizes and so on) with a number of backdoors in the form of inline assembly, special intrinsics and so on.
>
> But at the same time, the LLVM IR is also of a very different quality than GCC GENERIC, being strictly in SSA form. I have not looked into the
current
> GCC architecture in any detail, but I'd guess that LLVM itself starts approximately at the point where the middle-end does in GCC.
>

That is pretty much what I gathered.  SSA forms are something of a middle-end representation lowered from the GENERIC it receives from the frontend.

> Clang itself is obviously on a higher layer, but unlike GENERIC, its data structures are not designed to be reused for non-C-family languages. So,
the
> questions of whether its AST can represent every concept from another language or if it needs contains backdoors to a lower level are somewhat moot.
>

I didn't say it needs to contain backdoors, I was just pointing out that with LLVM you have the choice to drop to lower level if you choose to, I'd imagine at some cost to the optimiser too.  For example, you are free to implement your own calling convention from within the front-end in LLVM. Something of which is not considered something to be language-dependent by GCC, so you have no control over eg: *which* parameters are passed in registers, the only possible talking with the backend is through target hooks and setting the back-end attributes (such as 'regparm') to give hints.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 28/10/13 20:02, Iain Buclaw wrote:
> I don't see it that way.  Up until now at least I haven't seen
> anything they do that wasn't already do-able in GCC.  They just do a
> better job at PR (which is what you expect from Apple anyway).

Ah, that was the option I overlooked :-)

On 28/10/13 22:07, David Nadlinger wrote:
> Have you looked at the quality of error messages in Clang or its explicitly
> designed tooling/IDE integration API?

Yea, the quality of error messages with Clang is spectacular.  I still remember the first time I tried using it -- just on a whim -- and was shocked that code that compiled cleanly with GCC generated pages and pages of errors and warnings.  But once I'd got past the shock and actually read them, I realized that they were actually telling me very explicitly what to do to fix the problem, and that they were resolving unnecessary ambiguities in my source code.

But to be fair, we were talking about the backend, not the C/C++ compiler frontend.

On 28/10/13 21:22, Joakim wrote:
> Really?  The claims that llvm has a cleaner codebase, is easier to use because
> it's all properly split up into different libraries, and introduces new features
> like better error reporting: that's all "PR?"

It's my understanding from Iain's talks that the GCC backend is now much cleaner and friendlier than it used to be.  I don't know how that compares to LLVM, but it may be that reports of the relative cleanliness of the two codebases are out of date.

On 28/10/13 20:02, Iain Buclaw wrote:
> I don't see it that way.  Up until now at least I haven't seen
> anything they do that wasn't already do-able in GCC.

I confess I may be biased here because recently I've been finding that D code compiled with LDC seems to typically run faster than stuff compiled with GDC -- particularly code which makes any kind of serious use of stuff from std.algorithm or any other strongly generic parts of the language.

I can't imagine there are any fundamental frontend glue-code differences that are responsible for that, so I was assuming LLVM had a few areas where its optimizations worked better than the GCC middle/backend for various language constructs.

I did test just now making sure that I used GDC with -march=native just in case that was the issue, but there's still a performance gap.  The only other guess I have -- and it's a complete guess -- could it be inline-assembly related, that LDC gains a little here?

On Oct 29, 2013 7:16 AM, "Joseph Rushton Wakeling" < joseph.wakeling@webdrake.net> wrote:
>
> On 28/10/13 20:02, Iain Buclaw wrote:
>>
>> I don't see it that way.  Up until now at least I haven't seen anything they do that wasn't already do-able in GCC.
>
>
> I confess I may be biased here because recently I've been finding that D
code compiled with LDC seems to typically run faster than stuff compiled with GDC -- particularly code which makes any kind of serious use of stuff from std.algorithm or any other strongly generic parts of the language.
>
> I can't imagine there are any fundamental frontend glue-code differences
that are responsible for that, so I was assuming LLVM had a few areas where its optimizations worked better than the GCC middle/backend for various language constructs.
>
> I did test just now making sure that I used GDC with -march=native just
in case that was the issue, but there's still a performance gap.  The only other guess I have -- and it's a complete guess -- could it be inline-assembly related, that LDC gains a little here?

Inline assembler for dynamic array vector operations does improve speed by 20% over the generic loop that GDC uses (for small arrays at least).

LLVM certainly is making a name for itself in specialist benchmarks.  I'm not sure how well it fares in general usage cases...

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 29/10/13 08:36, Iain Buclaw wrote:
> Inline assembler for dynamic array vector operations does improve speed by 20%
> over the generic loop that GDC uses (for small arrays at least).
>
> LLVM certainly is making a name for itself in specialist benchmarks.  I'm not
> sure how well it fares in general usage cases...

I've not really been following specialist benchmarks (actually, from what I have seen, I thought the state of play was still, "Hey, LLVM has been improving really fast and is just about caught up with GCC now, but GCC is still slightly in front and stays that way with each new release").

But my own Dgraph's test benchmarks run consistently faster with LDC than with GDC: https://github.com/WebDrake/Dgraph

On Oct 29, 2013 7:36 AM, "Iain Buclaw" <ibuclaw@ubuntu.com> wrote:
>
>
> On Oct 29, 2013 7:16 AM, "Joseph Rushton Wakeling" <
joseph.wakeling@webdrake.net> wrote:
> >
> > On 28/10/13 20:02, Iain Buclaw wrote:
> >>
> >> I don't see it that way.  Up until now at least I haven't seen anything they do that wasn't already do-able in GCC.
> >
> >
> > I confess I may be biased here because recently I've been finding that
D code compiled with LDC seems to typically run faster than stuff compiled with GDC -- particularly code which makes any kind of serious use of stuff from std.algorithm or any other strongly generic parts of the language.
> >
> > I can't imagine there are any fundamental frontend glue-code
differences that are responsible for that, so I was assuming LLVM had a few areas where its optimizations worked better than the GCC middle/backend for various language constructs.
> >
> > I did test just now making sure that I used GDC with -march=native just
in case that was the issue, but there's still a performance gap.  The only other guess I have -- and it's a complete guess -- could it be inline-assembly related, that LDC gains a little here?
>
> Inline assembler for dynamic array vector operations does improve speed
by 20% over the generic loop that GDC uses (for small arrays at least).
>

Speaking of arrays, GDC up until recently allocated memory for every single [array, literal] in D code. This would give a noticeable slowdown in such code too.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 29 October 2013 at 07:37:05 UTC, Iain Buclaw wrote:
> LLVM certainly is making a name for itself in specialist benchmarks.  I'm
> not sure how well it fares in general usage cases...
>

Google guy say it is typically 5% to 10% slower on their code than GCC. Which is pretty good, but probably not good enough considering google scale.