Re: Proposed semantics for attributes in C++ (and in C?)
On Oct 15, 2006, at 3:12 PM, Mark Mitchell wrote: A typedef declaration which adds semantic attributes to a POD class type with no function members is valid, but creates an entirely new type, different from all other types except others formed by adding the same combination of semantic attributes to the same original class type. In the example above, if the typedef adds a semantic attribute, you may not pass an "S" to a function expecting a "T" or vice versa. Neither may you pass an "S*" to a function expecting a "T*", without an explicit reinterpret_cast. The name of "T", for linkage purposes, is "T", and there is no implicit "T::S" type; instead, however, there is a "T::T" type. (Various consequences follow; for example, typeid(T) gives you a type_info object that indicates that the name of the type is "T".) Note that this is an ABI change for any code that uses these. I agree that it seems cleaner to just disallow this practice entirely, particularly if it is a recent invention. In any case, having the compiler reject code that does not or will not work is a much better position to be in than silently miscompiling code. -Chris
Re: Threading the compiler
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote: The common case is that people just don't use the -j feature of make because 1) they don't know about it 2) their IDE doesn't know about it 3) they got burned by bad Makefiles 4) it's just too much typing Don't forget: 5) running 4 GCC processes at once at -O3 runs out of memory and starts swapping, limiting me to -j2 or -j3 on a 2G 4-core box. This is helped with threading. -Chris
Re: Char shifts promoted to int. Why?
On Dec 17, 2006, at 12:40 PM, Rask Ingemann Lambertsen wrote:
Hi.
I seem unable to get a QImode shift instruction from this code:
unsigned char x;
void qishifttest2 (unsigned int c)
{
x <<= c;
}
should have been generated. Also, notice the redundant zero extension.
Why are we not generating a QImode shift instruction?
Consider when c = 16. With the (required) integer promotion, the
result is defined (the result is zero). If converted to QImode, the
shift would be undefined, because the (dynamic) shift amount would be
larger than the data type.
-Chris
Re: Char shifts promoted to int. Why?
No. You're confusing some language you just invented with C. The operand of the shift operator is of type unsigned int. "x <<= c" is exactly the same as "((int)x) << c" It doesn't matter whether the promotion is explicit or implicit, the semantics are the same. ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) ) :: ((char)x) = ((char)( ((char)x) << ((int)c) ) ) if the shift count ((int)x) is semantically preserved. thereby conditionally shifting left ((char)x) by ((int)c) if c is less than the smaller of it's shifted operand's or target's precision (both being char in this instance) or otherwise returning 0; is semantically equivalent and typically more efficient on smaller lightly pipelined machines without needing to literally promote the shifted operand to int width. (I believe) Sorry, but you're incorrect. While it may be "logical" that shifting a value left more bits than its size will give you zero, this is not what C specifies. Further, as Paul B says, this behavior is often not provided by the hardware, e.g. on those obscure x86 boxes. If you want strictly defined behavior like this, use Java or another similar language, and be prepared to pay the performance hit when targeting a machine without semantics that match your expectations. OTOH, when targeting hardware that does properly handle oversized shift amounts, GCC should certainly perform this transformation. -Chris
Re: Char shifts promoted to int. Why?
On Dec 18, 2006, at 9:24 AM, Robert Dewar wrote: Chris Lattner wrote: Sorry, but you're incorrect. While it may be "logical" that shifting a value left more bits than its size will give you zero, this is not what C specifies. I am puzzled, what exactly *does* C specify in this case? I reread the thread, but it's not clear what the requirement of the standard here is (as opposed to what programmers might or might not expect, or what hardware does or does not do). C99 says: The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. Thus, it is undefined. -Chris
Re: Char shifts promoted to int. Why?
On Dec 18, 2006, at 9:53 AM, Robert Dewar wrote: Chris Lattner wrote: C99 says: The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. Thus, it is undefined. So the suggested transformation is indeed valid, which is what I thought, but some seem to be contesting this, though I don't see on what grounds. It only retains the proper semantics when targeting a machine that zeros the result of oversized left shifts. The original question was about X86 codegen, which doesn't have this behavior, so it is not valid. -Chris
Re: Char shifts promoted to int. Why?
On Dec 18, 2006, at 10:19 AM, Rask Ingemann Lambertsen wrote: On Mon, Dec 18, 2006 at 03:19:19AM +, Paul Brook wrote: Shifting >= the size of the value being shifted can and do give nonzero results on common hardware. Typically hardware will truncate the shift count. eg. x << 8 implemented with a QImode shift will give x, not 0. This is not true on i386. Ah, you're right: "The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used)." Thus, the transformation is safe in this specific case on i386. However, shifting a 32-bit value left by 33 bits would not be safe. -Chris
Re: false 'noreturn' function does return warnings
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote: On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote: I also think it would be good to have one option affecting it: turn __builtin_unreachable() into an abort(), or turn it into a "cannot be reached" marker. I think the former should be the default at -O0, the latter at -O1 and above. Note that a "cannot be reached" marker permits further optimization to delete code which leads up to it. Actually implementing that further optimization may call for adding appropriate warnings, probably controlled by -Wunreachable-code. I have experience with this approach, it works well: http://llvm.org/docs/LangRef.html#i_unreachable In the case that motivated this discussion, the instruction that would immediately go before the __builtin_unreachable() is a trap instruction, but the compiler does not know that it traps. It would be very bad if the compiler eliminated the trap, since it is the presence of the trap that keeps the function from returning. Nothing with side effects before an 'unreachable' can be removed, including an asm. Consider if the asm called a no-return function. -Chris
Re: Reduce Dwarf Debug Size
On Mar 2, 2007, at 7:57 AM, Ian Lance Taylor wrote: [ Moving from gcc-patches to gcc ] Chris Lattner <[EMAIL PROTECTED]> writes: The LLVM dev policy does not to try to define common sense. It is a rough guideline which can be deviated from when it makes sense. "Trust but verify" starts with trust. Lacking a benevolent dictator means that "trust but verify" does not work, because there is no way to implement the "verify" step. Or, rather: if "verify" fails, there is no useful action to take, except in the most obvious of cases. So my conclusion is that, for gcc, it is wise to require a formal confirmation process before somebody is allowed to approve patches or commit patches without approval from others. You are right that LLVM development and GCC development have many differences in structure. As you say, having a benevolent dictator simplifies things a lot, and I would argue that incremental development has an impact that is just as large. Others have said that an intermediate may exist between the two sides, one which is more suitable for the GCC development process. I agree, but I'll step out of the discussion and let you guys figure it out :) -Chris
Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
On Apr 1, 2007, at 10:42 PM, Joe Buck wrote: On Sun, Apr 01, 2007 at 02:20:10PM +0200, Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-04-01, o godz13:58, przez Paul Brook: If you're already switching compilers, moving to an already obsolete release (3.3) seems a strange choice. At this point I'd recommend skipping 3.x altogether and going straight to gcc4.1/4.2. Many of the improvements in c++ code generation were as a result of tree-ssa, you only get with 4.x. I wouldn't recommend it. One has to adapt gradually to the patience required to use the later compiler editions. No, one does not have to adapt gradually. It is no harder to switch from 2.95 to 4.1.2 than it is to switch from 2.95 to 3.3. Either way, you'll have to get out a C++ book, learn C++, and recode your code in actual C++. There will be some cases where going to 3.3 will require fewer changes, but the majority of the work is going to have to be done anyway. I believe the point being made was about compile times, not conformance. -Chris
Re: Information about LTO
On May 1, 2007, at 9:42 AM, Ian Lance Taylor wrote: "Sjodin, Jan" <[EMAIL PROTECTED]> writes: Hi I am new to GCC development and I have a few questions about LTO. What has been done since the last status report in January? I would also like to know what is most important to work on right now to make progress on LTO (e.g. type system, intermediate representation, reader/writer). What remaining work needs to be done to make LTO work for C? In the old status report a few things were mentioned: the front end was not complete, the type system was not being fully encoded and there are still some things that need to be explicitly represented in the IR. My take on it. Others may feel differently. Some langhooks have been removed. Removing langhooks one way or another is an important step in permitting the middle-end to work independently of any frontend. In addition, other flags that affect codegen and can be mixed and matched between translation units need to be adjusted eventually. For example, semantic options like -fstrict-aliasing, -ffast-math, - fforce-mem, -falign-loops, lots of optimization options (e.g. -fgcse, etc), and even target options like -malign-double, -march, etc. -Chris
Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.
Karel Gardas wrote: Yes, that's undefined, but I just define this class to be able to do: Foo* f = dynamic_cast(x); l = f->iiop_version(); there is nothing like delete involved. Anyway, I agree with you that emit warning about this is probably the right thing to do and so I will fix my code. I've run into this warning with C++ code as well, and it is quite annoying. There are lots of possible reasons to want to do this sort of thing, and adding a virtual dtor increases the size of the vtable for the class. It seems that the warning could be improved to be emitted when the *delete* is seen of a class without a virtual dtor (but that does have virtual methods). If you never actually do the questionable behavior, you'd never get the warning. It seems like a bug to emit it for the class definition. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.
On Fri, 4 Mar 2005, Mark Mitchell wrote: I've run into this warning with C++ code as well, and it is quite annoying. There are lots of possible reasons to want to do this sort of thing, and adding a virtual dtor increases the size of the vtable for the class. Yeah, there goes one whole pointer per class in your program image. :-) Seriously, you'd have to have a lot of classes and not very many objects before that got to be *too* big a deal. But, we do have customers who count every byte, so I'm not totally discounting this objection. For me, it's much more of an irritation factor than anything else. I agree that saving a couple pointers per class isn't a big deal. It seems that the warning could be improved to be emitted when the *delete* is seen of a class without a virtual dtor (but that does have virtual methods). If you never actually do the questionable behavior, you'd never get the warning. It seems like a bug to emit it for the class definition. Age-old debate: better to warn early about possibly broken interfaces, or late about definitely broken usage? I think that warning early, together with what DJ is calling fine-grained warning control is the best solution. I don't agree at all on this. It's not a matter of warning vs not warning: it's a matter of emitting bogus warnings *sometimes* when you can emit the proper warning *all of the time*. Given a choice of an accurate warning vs an warning that fires on a superset of the cases, I'd prefer the former. Warning "late" may just be a synonym for warning only where there is a problem, as opposed to in every translation unit that includes the header. :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.
On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
Age-old debate: better to warn early about possibly broken interfaces, or
late about definitely broken usage? I think that warning early, together
with what DJ is calling fine-grained warning control is the best solution.
I don't agree at all on this. It's not a matter of warning vs not warning:
it's a matter of emitting bogus warnings *sometimes* when you can emit the
proper warning *all of the time*. Given a choice of an accurate warning vs
an warning that fires on a superset of the cases, I'd prefer the former.
Warning "late" may just be a synonym for warning only where there is a
problem, as opposed to in every translation unit that includes the header.
:)
I understand where you're coming from. The reason I said age-old debate is
that we spent *weeks* worrying about this stuff for our error-checking tools
at CenterLine, and talking to customers, and so forth and so on, and there
was lots of passion on both sides. There really isn't a right answer.
Sure, I agree and I definitely see where you are coming from.
You're not looking at this from the perspective of a library developer who
wants to check header files as they're being developed.
I'm not sure I understand your point here. The library developer writes a
class, and does not *want* it to be destroyed through the base class. As
a library designer, I can intentionally make the dtor protected, making it
pretty clear that delete should not be called on the base class.
With the current implementation of the warning, as a library designer, I
am force to make the dtor virtual, even if there is no need in my library
for it to be so. This means that the dtors of derived classes will
implicitly be virtual, even if they don't need it. This (admitedly not
likely to be a problem in practice) introduced extra virtual function
calls because C++ doesn't have something like Java's "final" attribute
for classes.
Furthermore, even fine-grained warning control (at least on a per t-u
basis) doesn't help me with this. As a library developer, forcing all of
my clients to disable the (very useful) warning may potentially hide
problems in *their* code.
People actually make the same argument sometimes about things like:
void f() {
int *p = 0;
*p = 3;
}
saying "but I never call f, so I don't want a warning for it".
Languages like Python or LISP are the (extreme) logical extension of your
point of view: just start running the program and if anything goes wrong,
tell me about when it happens!
Sure fine, but this particular warning is not nearly as extreme as either
of those. Note that in the case of "f" there is no way to call the
function, so that is worth a warning. In the case we're discussing, there
are *perfectly valid* ways to use the class, which are not even really
that obscure.
In the end, I have to support older versions of GCC with my code, so this
discussion is somewhat academic to me. However, personally, I think that
refining this warning would be a simple quality of implementation
improvement. *shrug*
-Chris
--
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/
Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.
On Fri, 4 Mar 2005, Mark Mitchell wrote: Chris Lattner wrote: I'm not sure I understand your point here. The library developer writes a class, and does not *want* it to be destroyed through the base class. As a library designer, I can intentionally make the dtor protected, making it pretty clear that delete should not be called on the base class. The point is that it's a common error to forget the virtual destructor. If you're writing a library, and you put such a class in a header, you often want a warning *right then* -- not when a customer somewhere tries to use your library and uses delete on some class in your library. Sure, that makes sense. I agree that it's good to know early. :) With the current implementation of the warning, as a library designer, I am force to make the dtor virtual, even if there is no need in my library for it to be so. Yes -- what if a user of your library will need it to be virtual? In my mind, the times you want to silence the warning (without defining the virtual dtor) are when you *know* that it will never be used that way, because it's part of the contract of the class. I could agree that there should be no warning if the class declares a private operator delete. But, that kind of thing is a refinement. I think this would be a great refinement (if you extended it to protected dtors also). Given this, a library author would initially get the warning, then have two options for silencing it: a) define the virtual dtor if it makes sense, or b) mark the dtor protected/private to explicitly state the intention. Furthermore, even fine-grained warning control (at least on a per t-u basis) doesn't help me with this. As a library developer, forcing all That's not fine-grained. Fine-grained is a pragma/attribute you can put on the class to say "don't issue this warning about this class." Okay, sure, if there is a per-class way of disabling the warning (either something explicitly at the source level, like the above, or a #pragma gcc or something), that would be fine. I didn't know anyone was even considering doing this with GCC. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
LLVM 1.5 is out
Hi All, This is just some quick spam to announce the LLVM 1.5 release: http://mail.cs.uiuc.edu/pipermail/llvm-announce/2005-May/16.html http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew Among other things, this release adds beta IA64 and Alpha backends, support for general proper tail calls (as often requested by the functional language community), a new interprocedural sparse constant propagation pass, a new instruction selection framework, and many other nice new features. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Minimum target alignment for a datatype
Hi All, I'm trying to determine (in target-independent code) what the *minimum* target alignment of a type is. For example, on darwin, double's are normally 4-byte aligned, but are 8-byte aligned in some cases (e.g. when they are the first element of a struct). TYPE_ALIGN on a double returns 8 bytes, is there any way to find out that they may end up being aligned to a 4-byte boundary? Thanks, -Chris
Re: Minimum target alignment for a datatype
On Jul 22, 2005, at 11:27 AM, Dale Johannesen wrote: On Jul 22, 2005, at 11:07 AM, Chris Lattner wrote: I'm trying to determine (in target-independent code) what the *minimum* target alignment of a type is. For example, on darwin, double's are normally 4-byte aligned, but are 8-byte aligned in some cases (e.g. when they are the first element of a struct). TYPE_ALIGN on a double returns 8 bytes, is there any way to find out that they may end up being aligned to a 4-byte boundary? #pragma pack or attribute((__aligned__)) can result in arbitrary misalignments for any type. Understood. I'm just looking for the minimum type alignment without user alignment. It appears that this is impossible to get from the targets, due to the way the targets can override type alignments in (almost completely) general ways. Is this true? -Chris
Re: Minimum target alignment for a datatype
On Jul 22, 2005, at 12:33 PM, Mike Stump wrote:
On Friday, July 22, 2005, at 11:07 AM, Chris Lattner wrote:
I'm trying to determine (in target-independent code) what the
*minimum* target alignment of a type is. For example, on darwin,
double's are normally 4-byte aligned, but are 8-byte aligned in
some cases (e.g. when they are the first element of a struct).
TYPE_ALIGN on a double returns 8 bytes, is there any way to find
out that they may end up being aligned to a 4-byte boundary?
I'm having a hard time with the simplicity of your question:
I don't know if there is a good answer, unfortunately.
/* The alignment necessary for objects of this type.
The value is an int, measured in bits. */
#define TYPE_ALIGN(NODE) (TYPE_CHECK (NODE)->type.align)
On darwin, for a 'double' this will return 64.
/* 1 if the alignment for this type was requested by "aligned"
attribute,
0 if it is the default for this type. */
#define TYPE_USER_ALIGN(NODE) (TYPE_CHECK (NODE)->type.user_align)
I'm not interested in user alignment.
/* The alignment for NODE, in bytes. */
#define TYPE_ALIGN_UNIT(NODE) (TYPE_ALIGN (NODE) / BITS_PER_UNIT)
This is just 64/8.
? Certainly, I don't expect that to answer your question, but I
don't understand why.
The problem I am running into is that the double in this struct is
only 4-byte aligned on darwin:
struct X { int A; double B; };
This is modified by things like ADJUST_FIELD_ALIGN and
ROUND_TYPE_ALIGN. As such, I don't think there is a way to get this
alignment in a target-independent way. Does that sound right?
Thanks!
-Chris
Re: Minimum target alignment for a datatype
On Jul 22, 2005, at 12:42 PM, Andrew Pinski wrote:
struct X { int A; double B; };
This is modified by things like ADJUST_FIELD_ALIGN and
ROUND_TYPE_ALIGN. As such, I don't think there is a way to get this
alignment in a target-independent way. Does that sound right?
You want the alignment of B in that struct in source code and not
in GCC?
If so you want to do:
struct X { int A; double B; };
int f(void){struct X b; return __alignof__(b.B);}
Nope, I'm trying to use this in target-independent GCC code, not
source code. The reason I can't do something like the above (which
amounts to looking at TYPE_ALIGN or DECL_ALIGN) is that I don't
*know* all the ways that double can be used, and how the target will
change its alignment. IOW, I'm looking for
give_me_the_minimum_alignment(double), which, on darwin, because of
the above, is 4 bytes.
As RTH pointed out, it appears that there is no interesting minimum
that I can get.
Thanks all,
-Chris
Re: Minimum target alignment for a datatype
On Jul 22, 2005, at 1:14 PM, Richard Henderson wrote:
On Fri, Jul 22, 2005 at 11:30:40AM -0700, Chris Lattner wrote:
Understood. I'm just looking for the minimum type alignment without
user alignment. It appears that this is impossible to get from the
targets, due to the way the targets can override type alignments in
(almost completely) general ways. Is this true?
For !STRICT_ALIGNMENT, there is no interesting minimum.
After talking to people on IRC about this, some have mentioned that
this may be a bug in the darwin-ppc target description. Consider
this (untested) code:
struct X {
int A; double D;
};
void test(double *P) {
// alignof(double) == 8, but the dynamic alignment of P is only 4.
memset(P, 0, sizeof(double));
}
void problem() {// This could be in another translation unit.
struct X a;// 4 byte alignment.
test(&a.D);
}
The problem in this case is that the optimizer cannot assume that a
T* is at least as aligned as TYPE_ALIGN(T) in this case. People have
pointed out that the alignment of double could be represented as 4,
and increased when necessary (instead of represented as 8 and reduced
when needed).
I have no idea whether this is right or wrong, but as Dale recently
noticed, TYPE_ALIGN leaks out to user code through __alignof__, so
changing it may not be practical.
Anyone have any thoughts or opinions? This may have impact on a
number of things, including any pointer alignment analysis.
-Chris
Re: front-end that translate C++ to C
On Mon, 25 Jul 2005, Daniel Berlin wrote: On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote: Hi all, Are there any open-source(or free) front-end which translates C++ to C? I could find some commercial things - Comeau, AT&T Cfront, etc., but these have many limitations(especially, It's too difficult to get cfront because there are few cfront-based compiler at present) LLVM ( http://llvm.cs.uiuc.edu/ ) ? It use modified gcc 3.4 as C/C++ frontend and it can emits portable C code. Depends what you mean by portable. You can't take the output of the gcc llvm frontend on one platform, and run it on another, like cfront could. The sizes, alignments, etc, of things will be different, where people use sizeof(x), etc, in their code. Unless you hacked up the C frontend to give you sizeof_expr, etc. It isn't portable in that sense. Like Tom Tromey mentions, anything that deals with code that comes out of the preprocessor isn't "portable" in that way. It is portable in the sense of being able to use any standard ANSI C compiler to compile the code, which gives you a pretty portable C++ implementation. We have had quite a few people say they are using LLVM as a replacement for old and out-dated CFront-based vendor C++ front-ends. Using LLVM in this way allows them to use the GCC 3.4 parser and libstdc++ which is usually far better than what they are dealing with. Getting IPO and the other advantages that LLVM provides is just a perk that people with embedded devices (or other systems with constrained resources) particularly enjoy. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: -Wuninitialized issues
Jeff Law wrote: > I prefer consistency in warnings, regardless of optimization level. I disagree and I think we have a significant contingency of users that would disagree -- if optimizations allow us to avoid false-positive warnings, then we should use that information to avoid those false positive warnings. Jeff, I completely agree with you for some class of users (users being developers who use GCC but don't hack on GCC itself). OTOH, there is also a very large class of users (like myself) who have to write code that works well across several different compilers. In this capacity, having GCC be clever is not a good thing: if GCC is silent where a less clever compiler will warn, I will have to fix the warning *anyway* and won't know about it until someone else complains (I use GCC as my primary development compiler). In addition, I will assert that GCC's cleverness often causes it to emit FAR MORE warnings than those compilers that are not clever. For example, consider the following code: int X; if (somepredicate(A, &X)) use X; Prior versions of GCC (and most other compilers) assumed that since somepredicate is passed the address of X, that it may initialize X, thus not emitting a warning at the use site. Newer versions of GCC inline somepredicate and then emit a bogus warning: "X" is only assigned to (and used) in the case where somepredicate returns true, and GCC loses this information (it is probably missing a jump threading opportunity). While the above case can certainly be fixed in the future, the point is that every time a new GCC version comes out, we have to add MORE initializers to silence bogus warnings: its cleverness has inevitably (at least for 3.4, 4.0, and 4.1 mainline) resulted in more bogus warnings being emitted. I don't see any way to stop this, as there will always be cases that cannot be handled, and the optimizers are a fundamentally fragile thing to depend on for this (this being part of GCC's "user exprerience"). For users like myself, I would really like to have an option to switch the unused var warning to be emitted from the *front-end* where it works when compiling with optimization disabled (a huge feature in itself) and where the warnings are more stable. I know that it is impossible to guarantee that GCC will ever match "other compilers", and that there will be false positives (e.g. double diamond patterns), but for many uses this is perfectly fine (other compilers warn about the same cases, so these cases already have initializers). This is just MHO, but I know that many other developers are in a similar boat. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: -Wuninitialized issues
On Wed, 2 Nov 2005, Jeffrey A Law wrote: On Wed, 2005-11-02 at 12:01 -0600, Chris Lattner wrote: [ ... big snip ... ] For users like myself, I would really like to have an option to switch the unused var warning to be emitted from the *front-end* where it works when compiling with optimization disabled (a huge feature in itself) and where the warnings are more stable. I know that it is impossible to guarantee that GCC will ever match "other compilers", and that there will be false positives (e.g. double diamond patterns), but for many uses this is perfectly fine (other compilers warn about the same cases, so these cases already have initializers). I think it's worth noting that we build the SSA form even when we're not optimizing. Which in turn with running the maybe-uninitialized warning code early would give you the warnings you expect without needing to run the optimizers. That's why I don't think we need to push these warnings into the front-ends. Sure, running it as the first stage of the optimizers has the effect of making it have the properties I desire, without requiring the front-ends to duplicate the code. Such a feature would be great to have! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: -Wuninitialized issues
On Wed, 2 Nov 2005, Jeffrey A Law wrote: Sure, running it as the first stage of the optimizers has the effect of making it have the properties I desire, without requiring the front-ends to duplicate the code. Such a feature would be great to have! I think we've all agreed it's a good feature to have; I think all we're trying to work out is invocation details. ie, do we have another switch and if we do, is it enabled or disabled when the existing -Wuninitialized is enabled. My preference would be to make the "front-end" version of the warning be on with -Wall, and the existing version be enabled with a new flag. However, I don't feel strongly about this, and as long as there is a way to turn the "front-end" version on and the existing one off. Bonus points if it can be done without causing issues with older GCC's. :-) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: -Wuninitialized issues
Bernhard R. Link wrote: * Chris Lattner <[EMAIL PROTECTED]> [051102 19:28]: Jeff Law wrote: >> I prefer consistency in warnings, regardless of optimization level. >I disagree and I think we have a significant contingency of >users that would disagree Jeff, I completely agree with you for some class of users (users being developers who use GCC but don't hack on GCC itself). OTOH, there is also a very large class of users (like myself) who have to write code that works well across several different compilers. Why do you have to do something about a warning that is a clear false positive? .. I'd much prefer a warning about a "may be used uninitialized" on less clever compiler over the change to lose a "is used unitialized" warning some future more clever compiler may find You clearly fall into the "class of users" I mentioned above, that like *potentially* more precise warnings at any cost. To me, I would rather have that obvious false-positive case warned about. It will certainly be warned about on other (non-GCC) compilers, so the variable will have to be explicitly initialized in my code whether GCC warns about it or not. If you compile your code with *one specific version* of GCC and use no other compilers, I agree that accurate data-flow-based warnings are quite useful (particularly if/when all of the cases where data-flow-based warnings generating *more* false positives are fixed). All I'm saying is that I do not fall into that catagory, so I don't find them useful. I also posit that I'm not the only one writing portable code, and using GCC as a compiler to do so. Given this, I'm just saying that having some way to get "front-end" style warnings would be useful. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Link-time optimzation
Daniel Berlin Wrote: > > It [LLVM] is proven to be stable, high-level enough to > > perform any kind of needed optimization, > This is not true, unfortunately. That's why it is called "low level virtual machine". > It doesn't have things we'd like to do high level optimizations on, like > dynamic_cast removal, etc. For the record, this isn't really true at all. LLVM does already capture some high-level program properties, and is constantly being extended over time. I will note that it would be far easier to extend LLVM with the functionality you desire than to reinvent a whole new way of doing things. That said, wanting to stay as close as possible to gimple is a reasonable design point, and LLVM certainly isn't that. -Chris
LLVM/GCC Integration Proposal
Hi Everyone, At the request of several members of the GCC community, I'm writing this email to describe some of my short-term plans with GCC and describe an alternative to the recent link-time optimization [1] and code generator rewrite [2] proposals. For those who are not familiar with me, I'm one of the main developers working on the LLVM project (http://llvm.org/). One important way that LLVM is currently used is as a back-end for GCC. In this role, it provides a static optimizer, interprocedural link- time optimizer, JIT support, and several other features. Until recently, LLVM has only been loosely integrated with an old version of GCC (a 3.4 prerelease), which limited its effectiveness. Recently, at Apple, I have been working on a new version of the llvm- gcc translation layer, built on GCC 4. This implementation links the LLVM optimizers and code generator directly into the GCC process, replacing the tree-ssa optimizers and the RTL code generator with the corresponding LLVM components when enabled. The end result is a compiler that is command line compatible with GCC: 'gcc -S t.c -o t.s' does exactly what you'd expect, and most standard command line options are supported (those that aren't are very specific to the design of the RTL backend, which we just ignore). I plan to have this work committed to the Apple branch within a month. Though not yet implemented, we intend to support link-time optimization with many design constraints that match the recent proposal [1]. Because LLVM already currently supports link-time optimization and has an architecture that makes it straight-forward, this work mainly amounts to changes in the GCC compiler-driver. If you're interested in the link-time IPO architecture, there are documents that describe the high level ideas [10,11] with some (potentially out of date) implementation information. In this email, I want to briefly talk about the strengths that LLVM brings to the table, some of the implementation details of my integration work, some of the important ongoing work that we are working on, and answer some of the hot questions that will inevitably come up. :) Strengths of LLVM LLVM is a modern and efficient compiler framework built out of libraries with well defined APIs. As I mentioned above, LLVM provides an optimizer and code generator. It also provides several other components I won't discuss here. If you are interested, please see LLVM's extensive documentation [9] for more information. The LLVM mid-level and interprocedural optimizer work on a common representation (the LLVM IR), which is a three-address SSA-based representation that is somewhat similar to GIMPLE. It is fully specified [3], is easy to analyze and manipulate [4], and is very memory efficient (for example, it takes about 50M of memory on a 32- bit host to hold the IR for all of 176.gcc, which is about 230K LOC). The IR has a text form (suitable for compiler dumps and fine- grained regression testing) and a 100% equivalent compressed binary form (suitable for interchange between compile-time and link-time optimization steps), both of which correspond to the in-memory IR. The IR supports several features that are useful to various communities, including true tail calls, accurate garbage collection, etc. The IR is continuously evolving to add new features, and we plan several extensions in the future. The optimizer itself has a full suite of standard scalar optimizations and also includes a collection of interprocedural optimizations and interprocedural analyses, some of which are quite aggressive [5] (though this particular set is not enabled by default). The optimizer is fully modular, which allows us to have nice tools for working with the IR and optimizer, including an automated bug finding tool [6] which makes tracking down miscompilations and ICEs really easy. The LLVM code generator is built on modern techniques. For example, it uses pattern-matching DAG-based instruction selection, maintains SSA form up until register allocation, represents code in a form quite similar to the "compressed RTL" proposal [7], and supports dynamically loaded targets. We currently have stable code generators for PowerPC and X86, with targets for Alpha, IA-64, and Sparc also available, but less stable. LLVM can also emit C code, which allows it to support systems for which we do not have a native code generator implemented. The design of the register allocation components is very close to that proposed in Andrew MacLeod's recent proposal [2]. We have separate instruction selection, global coalescing, and register allocation stages, have a spiller that does simple local register allocation, etc. We currently support multiple pluggable register allocators, to (for example) support quick -O0 compiles, and to support targets who want to h
Re: LLVM/GCC Integration Proposal
Daniel Jacobowitz writes: As describe above, we won't support every target that GCC currently does. Three options are possible: Chris tells me that an LLVM->GIMPLE translator wouldn't have target dependencies. I'm not 100% sure I buy that, but I'll take it as given for now (if not they should be pleasantly small). So suppose we implement that. It seems like a much better choice than RTL anyway. I'm not sure exactly what you mean by target dependencies, but everything target dependent has to (by definition) be represented in the LLVM code already. LLVM makes things like "implicitly passing a pointer when returning a struct" explicit in the representation, as well as funny ABI things like passing FP values in integer registers. Given that this is already handled, translating to GIMPLE should be quite straight-forward. GIMPLE and LLVM are really quite close to each other: I've built the LLVM to GIMPLE translator in about 2-3 weeks, and most of that time has been figuring out target hooks to do the target-specific lowering correctly. (A) What bits of LLVM would we be bypassing, and how badly would we miss them? A system that used LLVM for the mid-level IR and then converted back to RTL would enjoy all of the benefits of the LLVM IR (compactness, ease of manipulation, testability, modularity, etc) but would just not have the code generator. I see this as a great intermediate point that would be good for migrating targets if and when desired. For example, targets that the GCC backend currently serves well could stay with the RTL backend until the LLVM targets improve (or exist :) ), and those targets that are better served by the LLVM backend could use it. One example area where LLVM excels is lowering of code in the backend (e.g. promoting small values to GPRs for RISC machines, and breaking up large integer values for targets without 64-bit registers). (B) What bits of GCC would we be bypassing, and how badly would we miss them? Presumably, many of the shiny new tree optimizers. Ow. But GCC was not in any state to do this sort of surgery a year ago, I think. Quite true. I'll let others comment about the implications of that. One very important point is that because GIMPLE and LLVM are very similar in spirit, optimizers could easily be moved over (just like the LLVM reassociation pass was moved over to GCC). I assert that the *implementation* of the LLVM IR is lighter weight than the current "tree"-based GIMPLE IR (though they are both very close in spirit to each other), which helps with memory usage and compile times. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
Richard Guenther writes: I would propose to even think of doing only IPO at LLVM and go back to gimple for the rest of the tree-ssa pipeline. At least that should be possible. Would we get link-time optimization this way, or is the LLVM link-time optimization architected differently? Sure, given an LLVM -> GIMPLE translator, this would certainly work. One thing that is useful to keep in mind is the desire to perform scalar optimizations before IPO. With translators both ways, you could choose to make these optimizations be either tree-ssa or LLVM (or a mix). Also, integrating LLVM addresses the weakness of our middle-end IR, but stays with this IR for our frontends. One important aspect of this work is that it changes tree structures into something that are only used by the front-end, not the optimizers. Because of that, it is corresondingly easier to change trees, and making them work really well for front-ends could be a follow-on project. Only the Ada frontend seems to be in a state to maybe support direct frontend IR to LLVM translation. Sure, also maybe Fortran? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sat, 19 Nov 2005, Joseph S. Myers wrote: On Fri, 18 Nov 2005, Chris Lattner wrote: 1. The build system is taught about C++ code. With toplevel bootstrap this will bootstrap libstdc++ so that the compiler ends up linked with the new libstdc++ not the (in general ABI-incompatible) old one? (This question applies to all projects involving C++ in GCC.) No, my personal configure-fu is too weak to attempt this, and I haven't dug into the problem yet. I currently depend on there already being both a native C++ compiler (like Ada depends on having a native Ada compiler) and that the libstdc++'s are compatible. This is a deficiency in the current implementation, not something that is unsolvable. While it has many virtues, LLVM is still not complete, and we are investing in adding the missing features. In particular, this system is missing two key features to be truly useful: debug info support and inline asm support. Apple is currently investing in adding both these features, as well as adding vector support. What (on any one target of your choice) is the GCC testsuite status when LLVM-enabled, compared to that without LLVM, and are most of the regressions fixed by the addition of debug info, inline asm and vector support? I'm sorry but I haven't gotten to that point yet. I've been working on the integration project for only about 3 weeks now, so I haven't had a chance to do as much testing as I would like (which is why I suggested not merging for a month). Basically right now things are working well enough for me to build and run (correctly :) ) several dozen small-to-medium sized GUI apps written in C and ObjC on PowerPC. If you're familar with the Apple Xcode distribution, I've basically been working on apps out of /Developer/Examples. Everything I have tried (which is all of the large programs and many of the small ones) work fine. I intend to get C++ up and running as well as doing Dejagnu testing before actually merging into the Apple branch. (Once debug info support is added, the same question applies regarding GDB testsuite status.) Clearly, as we bring up debug info support we will use all of the suites to make sure we've done it right! :) Do you propose annotating testcases for features not supported with LLVM so they are XFAILed when configured with --enable-llvm? (XFAIL would be right for features the compiler should support but LLVM doesn't yet; UNSUPPORTED for tests of some incidental feature of the current back-end implementation which it makes sense for replacement infrastructure not to support. A switch to LLVM as the default back-end for a target would require no such XFAILs for that target, though there might be UNSUPPORTEDs, buggy testcases might be fixed or removed and features might be removed through the usual deprecation process. dg-xfail-if and dg-skip-if with an llvm effective-target keyword are the way to annotate the tests.) I don't have any strong plans or feelings on this. My initial idea was to have a staged approach, something like this: 1. Initially the work is done on a branch (e.g. the Apple branch) and must be explicitly enabled (e.g. with --enable-llvm). Implementation of missing features continues. I should note that the patch doesn't tie into anything Apple-specific in the Apple branch. 2. When the basics are finished (e.g. inline asm, debug support, vectors), I would consider it ready to merge to mainline. At that point, adjusting XFAIL markers would make sense. The big question is the --enable-llvm configure option. Without an LLVM->GIMPLE or LLVM->RTL translator, it seems impossible to merge LLVM to mainline without the configure option. Having this translator has advantages other than supporting all of the GCC targets: it allows more flexible choice of what is part of LLVM and what isn't. It also allows use the new RTL-based register allocator work when it comes online. If anyone is interested in working on the translator, it would be a great help. I expect that my hands will be full of various front-end translation and LLVM extension work for the next few weeks, so I personally won't be able to build it for some time. Finally, I should note that the patch isn't a secret. I'm waiting to merge it in until it is more tested and feature complete... I'm not trying to hide it. If anyone wants a copy, please just let me know and I'll be happy to provide it. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
Kenneth Zadeck writes: This quickly becomes difficult and messy, which is presumably why the link-time proposal allows the linker to "give up" linking two translation units. The reason for the complexity of the type system handling in our proposal was motivated primarily by two concerns: 1) We need to keep track of the types so that they are available for debugging. ... loosing all the type information before you start did not seem the correct plan. This is exactly my point. The problem here is NOT the fact that the optimization representation can't represent everything that the debug information does. The problem is that your approach conflates two completely separate pieces of information. Consider: 1. Debug information must represent the source-level program with 100% fidelity. At link time, the debug information must be merged (and perhaps optimized for size), but you do not need to merge declarations or types across language boundaries, or in non-trivial cases. 2. An optimization representation need not (and if fact does not want to) represent the program at the source-level. However, it *must* be able to link declarations and types across modules and across languages without exception (otherwise, you will miscompile the program). Designing a representation where this is not practically possible requires a back-off mechanism as your proposal has outlined. To me, the correct solution to this problem is to not try to combine the representations. Instead, allow the debug information to capture the important information that it does well (e.g. types and declarations in a language-specific way) and allow the optimization representation to capture the semantics of the program in a way that is as useful for optimization and codegen purposes as possible. This approach is the one we have always taken with LLVM (except of course that we have been missing debug info, because noone got around to implementing it), which might explain some of the confusion around "lacking high-level information". I personally cannot guarantee that GCC (or for that matter any optimizing compiler) can correctly cross inline and compile a program if the types in one module are not consistent with the types in another module. Just because the program happens to work correctly when separately compiled is not enough. This is a direct result of the representation that you are proposing to use for IPA. LLVM is *always* capable of merging two translation units correctly, no matter where they came from. We do this today. If you look back to my 2003 GCC summit paper (Sec4.4), I mention the fact that this is not a trival problem. :) When Mark and I started working on this proposal (and later the rest of the volunteers) we decided that this was not going to be either an academic exercise or just something to run benchmarks. I'm glad. While IMA is an interesting step in the right direction, it has not seen widespread adoption for this reason. I'm glad that your goal is to design something like LLVM, which always works. What that means to me is that the link time optimizer needs to be able to either generate correct code or give up in some predictable manner. Having the compiler push forward and hope everything turns out OK is not enough. Discretion is the better part of valor. I prefer to design the compiler so that neither 'giving up' nor 'hope' is required. This is an easily solvable problem, one that LLVM has had right for several years now. I think that taking advantage of mixed C, C++ or C and Fortran programs is going to be hard. I don't agree. But it is what the GCC customers want and there is a desire to accommodate them if possible. Outside benchmarks, many programs are made up of different language components. There are of course the trivial cases (such as optimizing across JNI/CNI/Java and C/C++ code), but many programs, particularly large ones, have pieces written in multiple languages. I believe Toon was recently talking about his large weather program written in Fortran and C (though I could be confusing Toon's program with another one). -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sun, 20 Nov 2005, Steven Bosscher wrote: On Saturday 19 November 2005 18:56, Chris Lattner wrote: Only the Ada frontend seems to be in a state to maybe support direct frontend IR to LLVM translation. Sure, also maybe Fortran? I wouldn't count on it... Can you explain what you mean? The context above was speculating about the possibility of reducing dependency on the 'tree' data structure. My impression was that Fortran used its own private IR (gfc_expr for example) that wasn't based on trees. I thought that it converted to trees as its interface to the rest of GCC, in which case, it is quite possible for it to convert to LLVM directly instead. I'm not necessarily advocating this, but it seems possible. Of course it's also highly like that I'm confused, as I know very little about the Fortran front-end. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sun, 20 Nov 2005, Steven Bosscher wrote: Can you explain what you mean? I mean it would take a complete re-write of the translation phase from gfortran's native program representation to GENERIC trees. Even if it is "quite possible" to make it write out LLVM directly, it would be a huge job. Basically it would mean a complete rewrite of the gfortran backend, which is IMHO highly undesirable even if it is possible. I for one would not support any project to do this. Ok, we understand and agree with each other then. I wasn't the one proposing elimination of front-end use of trees. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Tue, 22 Nov 2005, Joseph S. Myers wrote: On Sat, 19 Nov 2005, Chris Lattner wrote: This is a direct result of the representation that you are proposing to use for IPA. LLVM is *always* capable of merging two translation units correctly, So compilation options which change the semantics of GIMPLE are translated into local flags on the relevant code in LLVM (or failing that combined to the most conservative settings, but not all such options have such settings) - or it will be extended so that they are? Yes, exactly. LLVM isn't all the way there yet, but it is making progress. For example, we want to be able to say that the overflow behavior of an integer add is one of: undefined, signed/unsigned-saturating, 2s complement, or trapping on a per-instance basis. This is needed to efficiently support languages like MSIL which have trapping and non-trapping versions of arithmetic operations among other things. Examples: -ftrapv -fwrapv -fno-math-errno -funsafe-math-optimizations -funsafe-loop-optimizations -ffinite-math-only -fno-trapping-math -frounding-math -ffloat-store -fsignaling-nans -fcx-limited-range. That sounds good if so; good implementation of C99 pragmas requires some of these settings to be appliable locally to particular blocks of code, which we don't currently have the infrastructure to do. Precisely. (*Any* combining of separately compiled translation units needs some way to deal with this problem - semantics depending on global variables - as well as for the places where the semantics of GIMPLE depend on langhooks which are different for different languages. Of course all globals and hooks should be audited for such implicit effect on semantics.) Yup, the idea is to be able to support things like the C99 pragmas for FP control, capture the semantics of FORTRAN parentheses, etc. That said, while in cases of such different options combining is desirable, there are cases where refusing to combine is a feature not a bug - if the user program can be detected to have incompatible translation units (e.g. where the same named function takes different types of arguments) then telling the user is useful, and if the program has some of the stranger combinations of types that may or may not be valid in C (DR#314 and subsequent discussion in Mt Tremblant minutes) then diagnosing this is also useful. Of course it's not the optimizer's job to diagnose such things, but infrastructure to diagnose them (possibly quite separate from that for optimization) can be useful. Absolutely. LLVM does not currently provide this natively (it tries to integrate as seamlessly as possible, including emulating the expected behavior in the case where prototypes don't match, etc), but it could be extended to do this if desired. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Daniel Jacobowitz wrote: The initial impression I get is that LLVM involves starting from scratch. I don't quite agree that this is necessary. One of the engineering challenges we need to tackle is the requirement of keeping a fully functional compiler *while* we improve its architecture. Most of your concerns seem to be based on this impression; I don't think it's right. I'll keep this brief since others can probably answer the details more accurately than I can. FWIW, I completely agree with Daniel's message here. LLVM as a backend, i.e. replacing everything from GIMPLE -> assembly, would involve a lot of starting from scratch. e.g. your later example of limited target support. One of the options Chris proposed is an optional GIMPLE -> LLVM -> GIMPLE process, in which: Correct. I think that this is, by far, the most logical first step. As the LLVM code generators mature, enabling them on a per-target basis can make sense. If the GCC RTL backend improves (e.g. with the new RA design), perhaps the transition will never occur. (A) the LLVM step is only necessary for optimization - I like this for lots of reasons, not least being that we could bootstrap without a C++ compiler. Great point. (B) the LLVM register allocator, backend, et cetera would be optional or unused, and the existing GCC backends would be used instead. Which are there today, need some modernizing, but work very well. Exactly. The LLVM -> GIMPLE translator does not exist yet; I believe Chris has a prototype of the GIMPLE -> LLVM layer working, and it took him under a month. I've been convinced that the opposite direction would be as straightforward. That's something a sufficiently motivated developer could hack out in the course of this discussion. It took under a month while multitasking and doing several other things :). I will send out the patch for some concrete ideas of what it involves. From what I understand, LLVM has never been used outside of a research environment and it can only generate code for a very limited set of targets. These two are very serious limitations. LLVM is indeed very new. At this point I believe it has been used outside of a research environment, but I can't say how thoroughly. Yes, it has been used by several industrial groups, e.g. people targeting unconventional devices and as a other things (JIT compiler for shaders in a graphics program). Apple is investing in it as well as mentioned before. Finally, I would be very interested in timelines. Neither proposal mentions them. My impression is that they will both take roughly the same amount of time, though the LLVM approach (as described) may take longer because it seems to have more missing pieces. My personal goal is to have debug info, vectorization, and inline asm fully working by Summer 2006, assuming no help outside of what Apple is investing. In terms of bigger goals, I intend to be compiling all of OS/X by next December (again assuming no major help). These are somewhat safe/conservative goals, but they should give some indication for my plans. With help, they would be significantly moved up. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Steven Bosscher wrote: On Tuesday 22 November 2005 17:20, Diego Novillo wrote: The initial impression I get is that LLVM involves starting from scratch. I thought it would basically "only" replace the GIMPLE parts of the compiler. That is, FE --> GENERIC --> LLVM--> RTL --> asm (trees) (trees) In the longer-term, you could maybe cut out the RTL part for targets for which LLVM has its own backend. This is not less evolutionary or revolutionary than tree-ssa was IMHO. Yes, agreed. For my work at Apple, we will probably end up using the LLVM backends. For the bigger GCC picture, making use of the RTL backends is essential. With our limited resources, we cannot really afford to go off on a multi-year tangent nurturing and growing a new technology just to add a new feature. It depends on who is going to invest these resources. Would you want to tell Apple they can't do this even though they can? ;-) :) But what are the timelines? What resources are needed? Interesting questions. Both projects obviously will take significant effort. But IIUC Chris has bits of the LLVM stuff already going, so he has the head-start (like tree-SSA did when LLVM was introduced to the GCC community, ironically? ;-) so maybe Chris can have a working prototype implementation within, what, months? The GVM plan could take years to get to that point... That is the plan. So my dummy prediction would be that the LLVM path would result in a reasonable product more quickly than the GVM plan -- iff RTL stays. Yes, totally agreed. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Benjamin Kosnik wrote: Another minor nit is performance. Judging by SPEC, LLVM has some performance problems. It's very good for floating point (a 9% advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in integer code. I'm sure that is fixable and I only have data for an old release of LLVM. But is still more work to be done. Particularly for targets not yet supported by LLVM. First off, this is for an extremely old version of LLVM (1.5yrs old, which represents 1/3 of LLVM's life :). For a better picture, you can take a look at some of the PowerPC numbers here: http://persephone.cs.uiuc.edu/~oscar/nightlytest/ It's hard to decode for people who are not used to staring at the Tables, but overall, LLVM is about 10-20% win over GCC (rough numbers) on PPC. The X86 backend is getting more investment now, as it has been without a maintainer for quite a while. I don't think its performance is as good as the PPC backend yet. In any case, going to RTL solves that issue. What about compile-time performance? LLVM has very good compile-time performance overall, and is one of the reasons that Apple is interested in it. It was designed with modern principles, and has had the advantage of not having to worry about legacy code to maintain. For -O0 compiles for example, I'm targeting a 20% speedup in the backend vs GCC 4 (using the native LLVM code generators). The individual LLVM optimizers are almost all very fast (though a couple need to be tuned), and the link-time stages are all quite fast (though obviously not as fast as not doing link-time optzn). For some examples, you can check out my thesis work, which is doing extremely aggressive context sensitive analysis and datastructure transformations in 3-4% of GCC compile times (i.e., single digit seconds for large programs like gcc). When dealing with large programs, it's "just" a matter of using good algorithms and data structures: there is no other solution. OTOH the specific questions about link-time compile-time performance, as others have pointed out, are not really that interesting. They would only be enabled at -O4 (or something) and the other link-time proposal would also have a substantial impact on compile-times (I posit that it will be far worse than compile times using LLVM). Besides using good algorithms and data structures, there is nothing you can do. Doing optimization at link time *will* be slower than doing it at compile time: the question is just how much. I'd actually like to make this a requirement, regardless of the option chosen. Agreed. For my work at Apple at least, compile-times are a very important part of the work (and one of the direct motivators). -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Richard Henderson wrote: On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote: I thought it would basically "only" replace the GIMPLE parts of the compiler. That is, FE --> GENERIC --> LLVM--> RTL --> asm (trees) (trees) This is certainly the only way to avoid losing functionality. I worry that this path will bitrot as 99% of folk use the llvm path straight through to assembly on i386. But perhaps a config option to force the rtl path, plus some automated testing, can prevent that from happening too fast. I'm not sure that's a real concern. Considering that (if people wanted to use the LLVM code generator at all) we would only be enabled for some targets, the mechanism would already be in place to disable the LLVM backend. If the mechanism is already in place, allowing people to disable it on targets where it is supported would be trivial. It depends on who is going to invest these resources. Would you want to tell Apple they can't do this even though they can? ;-) No, but we also might want to let Apple work on this for a year and then come back with something more concrete than "it should be easy". At this point, that is a reasonable decision to make. The work will progress without outside involvement, it would just go *faster* with outside involvement :). In practice, all this discussion boils down to is: when (and if) we merge the LLVM work into the main GCC tree. It can be disabled by default while in progress if desired, but are we going to make everyone interested in it use the Apple branch? The biggest technical problem I see with LLVM is actually the debug info. Frankly, I'm not sure I even want to consider LLVM until that's done. If it's as easy as Chris and Danny make it out to be, then they'll have it knocked off in short order. If not ... As far as scheduling goes, we will probably start intense work on that in January (given that the holidays are coming up). Waiting until that piece is in place would be reasonable. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Benjamin Kosnik wrote: Which is why i said "It's fine to say compile time performance of the middle end portions ew may replace should be same or better". And if you were to look right now, it's actually significantly better in some cases :( http://people.redhat.com/dnovillo/spec2000.i686/gcc/global-build-secs_elapsed.html And some more http://llvm.cs.uiuc.edu/testresults/X86/2005-11-01.html I'm not sure about accuracy, or versions of LLVM used, etc. No, this is not fair at all. The version you're comparing against is a debug version of LLVM. Debug versions of LLVM are literally 10x slower or more than release versions. Further, those compile times are with the "old llvm gcc", which is not only doing link-time optimization (which your GCC numbers aren't) it's also writing out a massive text file and reading it back in at compile-time. Although promising on some things (as Diego said), LLVM exectue and compile performance is a mixed bag. As I mentioned before, the X86 backend does not currently produce stellar code. The PPC backend is better, and the whole thing is a moot point if we're going to RTL :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
The actual LLVM integration patch
I threw the current version of the patch up here: http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz This is a patch vs the Apple branch as of a few weeks ago. The diff is in gcc.patch.txt, the new files are included in the tarball. Note, there are not enough caveats in the world to include with this. :) I literally ran to work, grabbed the diff and am uploading it. The patch has tested (with Apple code, not with dejagnu) at various points with '--enable-languages=c,objc --enable-llvm'. It's entirely possible that I was in the middle of something Friday and I forgot about them, and it is very clear that the patch is incomplete (was not intending to make it public for a month, so there are still FIXMEs and other missing pieces). Also, a lot of the changes in objc-act.c are LLVM-independent speedup patches I've fed to Fariborz separately for inclusion in mainline. However, it should at least give the list some concrete idea of what I'm talking about. :) If you have specific criticisms of the patch, I welcome the feedback, please send it to me privately. The main part of the translation process is in llvm-convert.cpp. Oh, if you want to test it, you have to download and build an LLVM tarball, and hack LLVMBASELIBPATH in the gcc/Makefile.in to point to the directory. An --enable-checking build uses the debug libraries, a normal build uses the release LLVM libraries. Clearly there is a lot of work to do on the patch, so don't go too hard on me. ;-) Again, suggestions for improvements are welcome. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 23 Nov 2005, Gabriel Dos Reis wrote: Diego Novillo <[EMAIL PROTECTED]> writes: | On Tuesday 22 November 2005 18:42, David Edelsohn wrote: | > I will work with the GCC SC and FSF on that issue once the licensing | > issue is addressed and we know LLVM is a viable option. | > | What purpose would that serve? I'm not concerned about the SC, initially. | It's the development community at large that needs convincing first. help me finish converting GCC to something compilable with a C++ compiler. Without having something concrete to test with, we'll go again over abstract arguments -- I did the conversion (many times) on my machine as a proof-of-concept. Lots of things kept (and are keeping) me busy. But, I'm back now and working on it. I'd not mind more hands/help. Why is this important? I'm finding that compiling GCC with a C compiler and using extern "C" around the headers works just fine. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Tue, 22 Nov 2005, Diego Novillo wrote: You will need to address two, potentially bigger, issues: license and implementation language. Over the last couple of years, there have been some half hearted attempts at suggesting C++ as a new implementation language for GCC. I would personally love to see us move to C++, but so far that has not happened. I am not quite sure how to address this. As mentioned, there is nothing I can do about the implementation language. If the GCC community doesn't like C++, they are welcome to ignore LLVM and/or take inspiration for it, but I'm personally not interested in being involved. You will need to get University of Illinois and past/present LLVM developers to assign the copyright over to the FSF. Yes, you've claimed it's easy, but it needs to be done. Otherwise, we are in limbo. We cannot do anything with LLVM until this is finalized. I would definately like to get this process running, but unfortunately it will have to wait until January. The main person I have to talk to has gone to India for Christmas, so I can't really start the process until January. Yes, I'm incredibly frustrated with this as well. :( -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Wed, 23 Nov 2005, Diego Novillo wrote: On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote: What about compile-time performance? Well, it's hard to say, I have not really used LLVM extensively. The only real data I have is compile times for SPECint: SPECint build times (secs) -O2 -O3 GCC 4.1.0 (20051117)354 398 LLVM 1.6 (-Wl,-native-cbe) 802 805 So there appears to be a factor of 2 slowdown in LLVM. However, I know LLVM has a separate GCC invokation. It seems as if it emitted C code that is then compiled with GCC (I'm using -Wl,-native-cbe). Wow, only 2x slowdown? That is pretty good, considering what this is doing. I assume you're timing a release build here, not a debug build. In any case, the LLVM time above includes the following: 1. An incredibly inefficient compile-time stage that is going away in the newly integrated compiler. This involves producing a giant .ll file, writing it to disk (cache) then parsing the whole thing back in. This was a pretty expensive process that existed only to avoid linking LLVM into GCC. 2. This time includes *full* linktime IPO (the old llvm-gcc wasn't integrated well enough to have -O options :( ). 3. This time includes the time to convert the LLVM code to C, write out a really large C file for the entire program, then fork/exec 'gcc -O2' on the .c file. Considering that the slowdown is only a factor of two with all that going on, I think that's pretty impressive. :) I don't think this would be standard procedure in an integrated LLVM. Chris, how would one compare compile times? Not using -Wl,-native-cbe implies emitting bytecode, right? Correct, if you're timing build times, eliminating the -Wl,-native-cbe will give you a sense for how expensive #3 is (which will just leave you with LLVM .bc files). I suspect that it is about 30% or more of the llvm-gcc time you report above. For another data point, you can compile with '-Wl,-native' instead of -Wl,-native-cbe which will give you the LLVM native X86 backend. It should be significantly faster and should provide another interesting performance datapoint (though admitedly probably not very good, due to the X86 backend needing work). In any case, one of the major motivating factors is reduced compile times. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Sun, 27 Nov 2005, Daniel Berlin wrote: On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote: What makes you think implementing LTO from scratch is different here? Here are the questions for LLVM as well as LTO folks. (To be fair, 1) Documentation How well is the documentation so that _new_ compiler engineer can become productive sooner ? There is no question that LLVM has much better documentation of IR and semantics than we do, See, e.g., http://llvm.org/docs/LangRef.html It has tutorials on writing a pass, as well as example passes, http://llvm.org/docs/WritingAnLLVMPass.html Yup, in addition, LLVM has several pretty good docs for various subsystems, the full set is included here: http://llvm.org/docs/ Another good tutorial (aimed at people writing mid-level optimization passes) is here: http://llvm.org/pubs/2004-09-22-LCPCLLVMTutorial.html Note that the organization of the 'llvm-gcc' compiler reflects the old compiler, not the new one. Other than that it is up-to-date. For a grab bag of various LLVM apis that you may run into, this document is useful: http://llvm.org/docs/ProgrammersManual.html 2) Testability of optimization passes How much precision one can get while testing particular feature, optimization pass? You can run one pass at a time, if you wanted to, using opt (or two, or three). Yup, however there is one specific reason that is important/useful. With the ability to write out the IR and a truly modular pass manager, you can write really good regression tests. This means you can write regression tests for optimizers/analyses that specify the exact input to a pass. With traditional GCC regtests, you write your test in C (or some other language). If you're testing the 7th pass from the parser, the regression test may fail to test what you want as time progresses and the 6 passes before you (or the parser) changes. With LLVM, this isn't an issue. Note that the link-time proposal could also implement this, but would require some hacking (e.g. implementing a text form for the IR) and time to get right. 3) Integrated tools to investigate/debug/fix optimizer bugs bugpoint beats pretty much anything we have, IMHO :). For those that are not familiar with it, here's some info: http://llvm.org/docs/Bugpoint.html If you are familiar with delta, it is basically a far more fast and powerful (but similar in spirit) automatic debugger. It can reduce test cases, identify which pass is the problem, can debug ICE's and miscompilations, and can debug the optimizer, native backend, or JIT compiler. 4) Basic APIs needed to implement various optimization techniques All the basics are there for scalar opts. There is no data dependence yet, but they have a fine working SCEV, so it's only a few months to implement, at most. Yup. LLVM has the scalar optimizations basically covered, but is weak on loop optimizations. This is something that we intend to cover in time (if noone else ends up helping) but will come after debug info and other things are complete. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: Thoughts on LLVM and LTO
On Wed, 23 Nov 2005, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: You will need to get University of Illinois and past/present LLVM developers to assign the copyright over to the FSF. Yes, you've claimed it's easy, but it needs to be done. Otherwise, we are in limbo. We cannot do anything with LLVM until this is finalized. I would definately like to get this process running, but unfortunately it will have to wait until January. The main person I have to talk to has gone to India for Christmas, so I can't really start the process until January. Yes, I'm incredibly frustrated with this as well. :( You, or somebody, can start the process by writing to the FSF, at [EMAIL PROTECTED], to see what forms the FSF would like to see. Ideally those forms will be acceptable to all concerned. More likely there will have to be some negotiation between the FSF and the University. For record, I sent an email to the FSF to get the ball rolling and find out what needs to be done. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: The actual LLVM integration patch
On Tue, 29 Nov 2005, Andrew Pinski wrote:
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double, double} seems wrong
for almost all targets except for PPC and MIPS which uses almost
the same 128bit fp encoding.
Thanks for the feedback! I will address these in the patch I actually
propose for submission.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
Re: LTO, LLVM, etc.
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 could easily be extended to be at the source-level version of Tree used in the front-ends, so that object files could contain two extra sections: one for LTO and one for source-level information. The latter section could be used for things like C++ "export" -- but, more importantly, for other tools that need source-level information, like IDEs, indexers, checkers, etc. I actually see this as a disadvantage. 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 tree representation. Sharing a tree dumper between the front ends and the middle-end would only make it more difficult again to move to sane data structures for the middle end and to cleaner data structures for the front ends. 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 representation will give you a representation that isn't very good for either use. In particular, the optimization representation really does want something in "three-address" form. The current tree-ssa implementation emulates this (very inefficiently) using trees, but at a significant performance and memory cost. The representation you want for source-level information almost certainly *must* be a tree. I think it is very dangerous to try to artificially tie link-time (and other) optimization together with source-level clients. The costs are great and difficult to recover from (e.g. as difficult as it is to move the current tree-ssa work to a lighter-weight representation) once the path has been started. 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. -Chris
Re: LTO, LLVM, etc.
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 tree representation. It's not that I would object to waking up one day to find out that the C++ front-end no longer used Tree, but it just doesn't seem very compelling to me. I agree with you. The 'tree' data structure is conceptually what we want for the front-ends to represent the code. They are quite similar in spirit to many AST representations. Sharing a tree dumper between the front ends and the middle-end would only make it more difficult again to move to sane data structures for the middle end and to cleaner data structures for the front ends. The differences between GIMPLE and C++ Trees are small, structurally; there are just a lot of extra nodes in C++ that never reach GIMPLE. If we had a tree dumper for one, we'd get the other one almost for free. So, I don't think sharing the tree dumper stands in the way of anything; you can still switch either part of the compiler to use non-Tree whenever you like. You'll just need a new dumper, which you would have wanted anyhow. The point that I'm arguing (and I believe Steven agrees with) is that trees make a poor representation for optimization. Their use in tree- ssa has lead to a representation that takes hundreds of bytes and half a dozen separate allocations for each gimple operation. From the efficiency standpoint alone, it doesn't make sense to use trees for optimization. Further, I would point out that it actually HURTS the front-ends to have the optimizers using trees. We are getting very close to the time when there are not enough tree codes to go around, and there is still a great demand for new ones. Many of these tree codes are front-end specific (e.g. BIND_EXPR and various OpenMP nodes) and many of them are backend specific (e.g. the various nodes for the vectorizer). Having the front-end and the back-end using the same enum *will* have a short term cost if the size of the tree enum field needs to be increased. -Chris
Re: LTO, LLVM, etc.
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 and uses, and trying to merge them into one representation will give you a representation that isn't very good for either use. I don't think that's entirely true. One of the nice things about WHIRL, at least in theory, is that the representation is gradually lowered throughout the compiler, but is never abruptly transitioned, as with GCC's Tree->RTL conversion. So, it's easier to reuse code, instead of having a Tree routine and an RTL routine that do "the same thing", as we do in several places in GCC. I understand where you are coming from here, and agree with it. There *is* value to being able to share things. However, there is a cost. I have never heard anything good about WHIRL from a compilation time standpoint: the continuous lowering approach does have its own cost. Further, continuous lowering makes the optimizers more difficult to deal with, as they either need to know what 'form' they are dealing with, and/or can only work on a subset of the particular forms (meaning that they cannot be freely reordered). In particular, the optimization representation really does want something in "three-address" form. The current tree-ssa implementation emulates this (very inefficiently) using trees, but at a significant performance and memory cost. The representation you want for source-level information almost certainly *must* be a tree. Instead, it's a long-winded way of saying that I don't agree that there's any inherent benefit to using completely different representations, but that I do agree that one wants the right representation for the job, and that Tree-SSA is not the best representation for optimization. So, if Tree-SSA is not replaced, it will almost certainly need to evolve. What sort of form do you think it could/would reasonably take? [1] Why hasn't it already happened? Wouldn't it make more sense to do this work independently of the LTO work, as the LTO work *depends* on an efficient IR and tree-ssa would benefit from it anyway? -Chris 1. I am just not seeing a better way, this is not a rhetorical question!
Re: Updated gcc+llvm patch
On Dec 6, 2005, at 4:35 PM, Rafael Ávila de Espíndola wrote: On Tuesday 06 December 2005 19:19, Chris Lattner wrote: This version of the patch has many bugs fixed and several rough corners rounded off (for example, there are no more hard coded paths in the makefiles anymore, and the llvm-independent objc changes are now in the apple branch instead of the patch). And the patch now includes the new files, instead of having a tarball. A small improvement to gcc/makefile.in is attached. Instead of linking to LLVMPowerPC.o unconditionally, it now uses $(target) to link with LLVMPowerPC.o or LLVMX86.o. Great, I applied it to my local tree, thanks! -Chris
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: Additionally to the obstacles to adopt LLVM mentioned by Diego, I named usage of C++ (although it has advantages too) and patents. LLVM should be checked for usage of compiler patents. Gcc people avoided many patents especially from Microsoft. We can not be sure right now about LLVM. Hi, For what it's worth, LLVM doesn't depend on any technology patented by Microsoft that I'm aware of. This seems to be an item of common confusion, so I'll clear it up here. The confusion is basically centered around the distinction between my PhD research work and LLVM itself. The thesis work I did at UIUC does relate closely to Steensgaard's pointer analysis work, which is patented by Microsoft. However, this thesis work is not currently used by LLVM, and certainly won't be incorporated directly into GCC (for obvious patent reasons), so this isn't an issue with LLVM adoption by GCC. If you or the Gelato group has any questions about LLVM, I'd be more than happy to answer them either on this list or over the phone. -Chris
Re: 8 Dec 05 notes from GCC improvement for Itanium conference call
On Dec 16, 2005, at 11:47 AM, Daniel Berlin wrote: On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote: On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote: Additionally to the obstacles to adopt LLVM mentioned by Diego, I named usage of C++ (although it has advantages too) and patents. LLVM should be checked for usage of compiler patents. Gcc people avoided many patents especially from Microsoft. We can not be sure right now about LLVM. The confusion is basically centered around the distinction between my PhD research work and LLVM itself. The thesis work I did at UIUC does relate closely to Steensgaard's pointer analysis work, which is patented by Microsoft. However, this thesis work is not currently used by LLVM, and certainly won't be incorporated directly into GCC (for obvious patent reasons), so this isn't an issue with LLVM adoption by GCC. The sad fact is it probably doesn't matter if it's actually run by default or not. It is built into the binary, exists in the source tree, and *can be run* by simply passing a command line option to opt. That's the thing. opt isn't part of the C/C++ compiler. This stuff isn't built into the binary, and cannot be run by passing an option to the C compiler. It does exist in the (LLVM) source tree, but if that's an issue, it can be remedied. This invariably counts as a "making of the patented invention", and is considered infringement, even if it's not run by default. If you made it not built into the binary, you would be on more solid legal ground (but even then they'd still sue you anyway :P). It's not built into the binary. Again, 'opt' is a developer tool and not part of the C/C++ front-end (the front-end never invokes opt, etc). However, I am certainly not a lawyer and defer to those who are :). If people would be more comfortable with the code out of the *llvm* distro, I can remove it, just let me know. In any case, this issue still has nothing to do with GCC integration. -Chris
Re: [llvm-dev] DragonEgg for GCC v8.x and LLVM v6.x is just able to work
> On Sep 4, 2017, at 8:13 PM, Leslie Zhai via llvm-dev > wrote: > > Hi LLVM and GCC developers, > > LLVM China http://www.llvm.org.cn forked DragonEgg > https://github.com/LLVM-China/dragonegg because: > > * Some subprojects are impractical or uninteresting to relicense (e.g. > llvm-gcc and dragonegg). These will be split off from the LLVM project (e.g. > to separate Github projects), allowing interested people to continue their > development elsewhere. > http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html > > * There are a lot of issues https://github.com/xiangzhai/dragonegg/issues so > I need smarter developers' help. Hi Leslie, Out of curiosity, what is motivating this work? What is the usecase for dragonegg these days, now that Clang has great C++ support? Are you interested in Ada + LLVM or some other frontend? -Chris
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote: > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to > the darwin assembler which effectively breaks LTO support for darwin. The > design > of LTO on darwin was based on the fact that mach-o object files tolerated > additional > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > assembler > appears to be strictly counting sections and objecting when these exceed 255. > This > breaks huge sections of the lto testsuite and prevents larger projects like > xplor-nih > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > reverts this > change, our only recourse would be to resort to an elf object container for > the lto > sections within the mach-o files (introducing an undesired dependency on > libelf for > FSF gcc on darwin). My understanding was that the lto design did not allow > the number > of sections required in the lto files to be reduced. Hi Jack, Please file a bug against the apple bug tracker explaining exactly what you need to work with some example .o files. -Chris
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote: > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made >>> to >>> the darwin assembler which effectively breaks LTO support for darwin. The >>> design >>> of LTO on darwin was based on the fact that mach-o object files tolerated >>> additional >>> sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the >>> assembler >>> appears to be strictly counting sections and objecting when these exceed >>> 255. This >>> breaks huge sections of the lto testsuite and prevents larger projects like >>> xplor-nih >>> to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple >>> reverts this >>> change, our only recourse would be to resort to an elf object container for >>> the lto >>> sections within the mach-o files (introducing an undesired dependency on >>> libelf for >>> FSF gcc on darwin). My understanding was that the lto design did not allow >>> the number >>> of sections required in the lto files to be reduced. >> >> If the problem is not fixed, we could always pack all the LTO sections into >> one section containing >> our own subsections. >> >> Honza > > Jan, > If this could be done without resorting to other container types (like elf), > it might be > the wisest approach for the long run. I've read through the mach-o > documentation and it > seems rather vague on the section limits. Even if Apple fixes Xcode (which > likley won't > happen for 6-9 months at best), we always we have to worry that they will > break this > 'feature' somewhere else in their tool chain. Better to follow the strictest > possible reading > of mach-o object format to protect ourselves from overzealous Apple interns. Yes, I agree that this is a better solution. This error was put into the linker to detect some overflow conditions for part of the code that expected the section number to only be a byte. It is likely that "things worked" only out of luck before. -Chris
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote: >> Yes, I agree that this is a better solution. This error was put into the >> linker to detect some overflow conditions for part of the code that expected >> the section number to only be a byte. It is likely that "things worked" >> only out of luck before. >> >> -Chris > > Chris, > Is there any documentation or example code on how to properly use > subsections in mach-o? > My fear is that we are moving from one poorly documented technique to another > which may well > have it own slate of hidden bugs. I'm not sure what you mean here Jack. ld64 is open source on the darwin page, and if you have all the developer bits installed, the format is "documented" in /usr/include/mach-o/. It's pretty clear all around that you can only have 256 sections. -Chris
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>
>>> Yes, I agree that this is a better solution. This error was put into the
>>> linker to detect some overflow conditions for part of the code that
>>> expected the section number to only be a byte. It is likely that "things
>>> worked" only out of luck before.
>>>
>>> -Chris
>>
>> Chris,
>> Is there any documentation or example code on how to properly use
>> subsections in mach-o?
>> My fear is that we are moving from one poorly documented technique to
>> another which may well
>> have it own slate of hidden bugs.
>
> I'm not sure what you mean here Jack. ld64 is open source on the darwin
> page, and if you have all the developer bits installed, the format is
> "documented" in /usr/include/mach-o/. It's pretty clear all around that you
> can only have 256 sections.
Sorry, I actually mean 255 of course, because of the NO_SECT sentinel. Here
are the relevant bits from nlist.h. I'm not sure how you expect the toolchain
to store more than 256 sections in a uint8_t.
This is not the conspiracy you are looking for.
-Chris
/*
* Format of a symbol table entry of a Mach-O file for 32-bit architectures.
* Modified from the BSD format. The modifications from the original format
* were changing n_other (an unused field) to n_sect and the addition of the
* N_SECT type. These modifications are required to support symbols in a larger
* number of sections not just the three sections (text, data and bss) in a BSD
* file.
*/
struct nlist {
union {
#ifndef __LP64__
char *n_name; /* for use when in-core */
#endif
int32_t n_strx; /* index into the string table */
} n_un;
uint8_t n_type; /* type flag, see below */
uint8_t n_sect; /* section number or NO_SECT */
int16_t n_desc; /* see */
uint32_t n_value; /* value of this symbol (or stab offset) */
};
/*
* This is the symbol table entry structure for 64-bit architectures.
*/
struct nlist_64 {
union {
uint32_t n_strx; /* index into the string table */
} n_un;
uint8_t n_type;/* type flag, see below */
uint8_t n_sect;/* section number or NO_SECT */
uint16_t n_desc; /* see */
uint64_t n_value; /* value of this symbol (or stab offset) */
};
/*
* If the type is N_SECT then the n_sect field contains an ordinal of the
* section the symbol is defined in. The sections are numbered from 1 and
* refer to sections in order they appear in the load commands for the file
* they are in. This means the same ordinal may very well refer to different
* sections in different files.
*
* The n_value field for all symbol table entries (including N_STAB's) gets
* updated by the link editor based on the value of it's n_sect field and where
* the section n_sect references gets relocated. If the value of the n_sect
* field is NO_SECT then it's n_value field is not changed by the link editor.
*/
#define NO_SECT 0 /* symbol is not in any section */
#define MAX_SECT255 /* 1 thru 255 inclusive */
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 12:07 PM, Jan Hubicka wrote: >> >> Yes, I agree that this is a better solution. This error was put into the >> linker to detect some overflow conditions for part of the code that expected >> the section number to only be a byte. It is likely that "things worked" >> only out of luck before. > > Interesting, so there is no -ffunction-section type tricks at darwin? Correct, darwin doesn't support that flag in a useful way. Instead, macho has a (poorly defined and understood) concept of "atoms" that the linker uses to slice things up. -Chris > > Pickling everything into single section seems indeed like easiest approach > here. > The question is who will volunteer to implement it ;) > > Honza
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote: > On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote: >> >> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote: >> >>>> Yes, I agree that this is a better solution. This error was put into the >>>> linker to detect some overflow conditions for part of the code that >>>> expected the section number to only be a byte. It is likely that "things >>>> worked" only out of luck before. >>>> >>>> -Chris >>> >>> Chris, >>> Is there any documentation or example code on how to properly use >>> subsections in mach-o? >>> My fear is that we are moving from one poorly documented technique to >>> another which may well >>> have it own slate of hidden bugs. >> >> I'm not sure what you mean here Jack. ld64 is open source on the darwin >> page, and if you have all the developer bits installed, the format is >> "documented" in /usr/include/mach-o/. It's pretty clear all around that you >> can only have 256 sections. >> >> -Chris > > Chris, > The mach-o reference has a cryptic mention of MH_SUBSECTIONS_VIA_SYMBOLS in > > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html > > MH_SUBSECTIONS_VIA_SYMBOLS—The sections of the object file can be divided > into individual blocks. These blocks are dead-stripped if they are not used > by other code. See Linking for details. Right, "subsections via symbols" is the concept of slicing up a section into "atoms" based on public labels. The linker uses this to do dead code elimination etc. I don't think this helps you at all though. I don't understand why you can't put arbitrary data into a single section. This is what the -sectcreate flag to the linker does, so it is simple, already supported, and tested. -Chris > > Although I don't think this helps us at all because none of the GNU_LTO > sections contain symbols. This is why I > am still perplexed by this assembler change. We followed the rules Nick > suggested of placing all of these GNU_LTO > sections at the end of the file and none contain symbols. In that case, it > would really seem that the assembler is > now blindly counting sections without respect to whether any of them actually > contain symbols. > Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mar 13, 2011, at 12:42 PM, Steven Bosscher wrote: > (sorry Chris, I forgot the list) > > On Mar 13, 2011, at 11:59 AM, Chris Lattner wrote: > >> Sorry, I actually mean 255 of course, because of the NO_SECT >> sentinel. Here are the relevant bits from nlist.h. I'm not >> sure how you expect the toolchain to store more than 256 >> sections in a uint8_t. > > How self-righteous, and misinformed. > > No-one is expecting to store >256 in a uint8_t. The structures you > quote only apply to symbol tables, which are references into sections > in Mach-O. But not all sections have symbols. None of the sections in > the GNU_LTO segment have symbols. That data structure only has to do with symbol tables. However, various tools that work on MachO have the exact same limitation in their internal data structures, since "there can't be more than 256 sections". I'm sorry that the toolchain doesn't work the way you'd like it to, but the right answer is still to plop whatever metadata you guys want into a single section. -Chris > > The documentation you should be quoting is the part about Mach-O > loader commands, and there is no limit AFAICT on the number of > LC_SEGMENT/LC_SEGMENT_64 loader commands. There is also nothing in the > segment command structures that suggests a limit of 255 sections. > > Besides, it worked before, which suggests that, well, it worked. > > This is not the limitation of Mach-O you are looking for. > > Ciao! > Steven
Re: Dealing with compilers that pretend to be GCC
Why not just implement the clang feature checking macros?
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check
Besides fixing the whole problem that this thread identifies, it doesn't
require cramming tons of macros into the initial preprocessor state, speeding
up compiler startup time.
-Chris
On Jan 21, 2012, at 12:14 AM, Basile Starynkevitch
wrote:
> On Sat, 21 Jan 2012 01:32:29 +0100
> Vincent Lefevre wrote:
>
>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
>>> May I politely suggest that this is the wrong place to complain about
>>> other compilers pretending to be GCC :)
>>
>> I think that's the fault of GCC, which should have defined a macro
>> for each extension.
>
>
> I agree with that. And I even hope that if GCC 4.7 defined several macros,
> one for each
> extensions, like e.g.
> __GCC_HAVE_INDIRECT_GOTO__ for the goto *x; feature
> __GCC_HAVE_STATEMENT_EXPR__ for statement expressions
> etc then perhaps in several years other compilers would do likewise. We just
> have to
> document our features and their corresponding macros...
>
> Regards.
>
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
Re: Dealing with compilers that pretend to be GCC
On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: > On 21 January 2012 00:32, Vincent Lefevre wrote: >> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: >>> May I politely suggest that this is the wrong place to complain about >>> other compilers pretending to be GCC :) >> >> I think that's the fault of GCC, which should have defined a macro >> for each extension. > > And what about the fact other compilers haven't defined such a macro > for each extension they implement, whether it comes from GCC or not, > is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check -Chris
Re: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
On Jan 29, 2012, at 1:30 PM, Georg-Johann Lay wrote:
> Hi,
>
> may I propose to change this message to a more user-friendly one?
>
> In most cases, the message is triggered by a typo like here:
>
> Int foo (void)
> {
>return 1;
> }
>
> A message like
>
> error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
>
> is just pain to the eyes, and apart from that it is not more helpful than a
> simple "syntax error before 'foo':
FWIW, Clang produces:
t.c:1:1: error: unknown type name 'Int'; did you mean 'int'?
Int foo (void)
^
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
:)
-Chris
Re: Dealing with compilers that pretend to be GCC
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: > Hello, > > Chris Lattner skribis: > >> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: >> >>> On 21 January 2012 00:32, Vincent Lefevre wrote: >>>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: >>>>> May I politely suggest that this is the wrong place to complain about >>>>> other compilers pretending to be GCC :) >>>> >>>> I think that's the fault of GCC, which should have defined a macro >>>> for each extension. >>> >>> And what about the fact other compilers haven't defined such a macro >>> for each extension they implement, whether it comes from GCC or not, >>> is that GCC's fault too? >> >> If fact, some do: >> http://clang.llvm.org/docs/LanguageExtensions.html#feature_check > > That seems like a very useful approach to solve the problem. > > The docs say that ‘__has_builtin’ & co. are macros. What do they expand to? 0 or 1. -Chris
Re: Dealing with compilers that pretend to be GCC
On Jan 31, 2012, at 4:58 AM, Marc Glisse wrote: The docs say that ‘__has_builtin’ & co. are macros. What do they expand to? >>> >>> 0 or 1. >> >> I understand. To put it another way, how are they defined? > > Compiler magic, like __LINE__ for instance? I am still not sure what you are > asking... Yes, they are compiler magic. __has_attribute() __has_extension() etc all work the same way as well. > Interestingly enough: > $ cat q.c > __has_builtin > $ clang -E q.c > Nice catch, fixed in r149397. Thanks! -Chris
Re: Dealing with compilers that pretend to be GCC
On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: >> >> Interestingly enough: >> $ cat q.c >> __has_builtin >> $ clang -E q.c >> > > Yes, that’s what I was asking. > > It makes me think that the old CPP predicates (info "(gcc) Obsolete > Features") would be more appropriate than compiler magic, with the > caveat that they’re presumably not widely supported. They are similar in spirit. The major difference between the two is that it is easy for __has_feature and friends gracefully degrade when a compiler doesn't support them, because you can do: #ifndef __has_builtin #define __has_builtin(x) 0 #endif in your code, but you can't do anything like this for #assertion. That and assertions don't have any coverage over the features that you're interested in, and the grammar doesn't have a good way to handle multiple cases like features/attributes/extensions/etc. -Chris
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
On Jul 22, 2009, at 2:58 AM, Paolo Bonzini wrote: On 07/22/2009 10:57 AM, Richard Guenther wrote: On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: Gregory Casamento wrote: As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. You're not forced to assign changes that you do not want to assign. I don't understand. Yes you are forced to assign copyright to the FSF for changes you contribute to FSF GCC. You are of course not forced to do this for your own forks of GCC. Yeah, if Apple didn't send the code to FSF GCC, the fact that Apple has an assignment does not count. They're not forced to assign changes that they do not want to assign -- as long as they keep the changes local, which they did for Objective C 2.0. The only way to know, would be to ask someone at Apple. If someone is seriously interested in merging pieces of the Apple GCC tree into the main FSF tree, and if there is a process in place to make the assignment happy, I would be happy to try to make it happen. The major caveats are that the Apple GCC tree isn't in great shape (it will take some work to make the objc2 changes "submission quality" because they may break the gnu runtime, be overly darwin specific, etc), Apple engineers will not be able to help with this work, and it may take some time to get the approval to assign copyright of the code. What is the process for getting a blob of code assigned to the FSF that is not just being committed into the tree? -Chris
Re: apple blocks extension
On Sep 15, 2009, at 9:04 AM, Richard Henderson wrote:
On 09/15/2009 08:28 AM, Vincent R. wrote:
I just was curious to know if closures in apple gcc(called blocks
from
what I read) is
also in mainline.
What is the status about this extension ?
It is unlikely that this will ever be brought into GCC, since
it appears to be largely identical to the C++0x Lambda feature.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf
There are major differences between lambdas and blocks, though they
serve a superficially similar purpose. If you are interested, there
is a ton of discussion online. Here are the two biggest differences:
The first difference is that every instance of a lambda gives you a
value of a new (anonymous) type, which makes them mostly only useful
with templates. Blocks literals give values of a predictable type,
which means that you can pass them around to non-templates. This is
also why they "work" in C. Yes, I know that there are various adaptor
classes that can be used with C++ lambdas to help work around this,
but this is in inherent part of blocks.
The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central
Dispatch" to work: you can write code that executes blocks
asynchronously or on other threads/work queues (after the function
containing the block has returned). A simple example is:
void print_on_different_thread(int X) {
run_asynch(^{
printf("Hi %d\n", X);
});
}
With lambdas, the closure would be go out of scope when
print_on_different_thread returns, but blocks allows "run_asynch" to
extend the lifetime of the block.
Blocks and Lambdas have intentionally different syntax, allowing them
to coexist peacefully in the same compiler / language. They are also
superficially similar to nested functions, but have other sets of
benefits. For example, blocks don't require executable stacks etc.
-Chris
Re: apple blocks extension
On Sep 16, 2009, at 11:12 AM, Vincent R. wrote: True, though Apple's entry in the copyright file says "assigns past and future changes" (I checked before the above e-mail). Certainly checking with the FSF is a good idea. Ian While we are discussing apple extension, is there a list of apple specific extension about C and objective compiler ? There isn't anything good, but some information is available here: http://clang.llvm.org/docs/LanguageExtensions.html -Chris
Re: apple blocks extension
On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote:
On 09/15/2009 12:35 PM, Chris Lattner wrote:
The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central
Dispatch"
to work: you can write code that executes blocks asynchronously or on
other threads/work queues (after the function containing the block
has
returned). A simple example is:
void print_on_different_thread(int X) {
run_asynch(^{
printf("Hi %d\n", X);
});
}
With lambdas, the closure would be go out of scope when
print_on_different_thread returns, but blocks allows "run_asynch" to
extend the lifetime of the block.
The lambda equivalent would be
void print_on_different_thread(int X) {
run_asynch([=]{
printf("Hi %d\n", X);
});
}
since X is captured by copy, run_asynch can do whatever it wants
with the closure and not worry about the original X going away.
The only difference between blocks and lambdas here seems to be
where you decide to copy the locals off the stack.
Can the lambda (containing X) be copied and put onto a queue? What is
its type?
-Chris
LLVM 2.6 Release
FYI, the LLVM project just pushed out its 2.6 release: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/33.html There is a lot of goodness in this release, which spanned 6 months instead of the usual 3. Of particular interest to the GCC community may be the 'DragonEgg' GCC plugin (http://dragonegg.llvm.org/), much better X86-64 code generation, and LTO support through the gold linker. There is a high level description of some of the other features in the release announcement and more technical detail in the release notes: http://llvm.org/releases/2.6/docs/ReleaseNotes.html Cheers, -Chris
Re: gccgo: A gcc frontend for Go, a new programming language
On Nov 11, 2009, at 12:43 PM, Joe Buck wrote: They weren't intended as a way of attaching complete new front ends or complete new back ends. That was the thing that RMS feared the most, and he had at least some justification: would we have a C++ compiler or an Objective-C compiler if the companies who employed the original authors had the alternative of hooking into GCC without contributing their code? There's some evidence that they would not have. I thought it *was* a goal to allow attaching new (GPL3 compatible) backends? -Chris
Re: detailed comparison of generated code size for GCC and other compilers
On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote: > On 12/14/2009 09:31 PM, John Regehr wrote: >> Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to >> agree with both of your suggestions. I'll re-run everything w/o frame >> pointers and ignoring testcases where some compiler warns about use of >> uninitialized local. I hate the way these warnings are not totally >> reliable, but realistically if GCC catches most cases (which it almost >> certainly will) the ones that slip past won't be too much of a problem. > > I also wonder if you have something like LTO enabled. No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch the 'CC1000SendReceiveP*' definitions because they are not static (unless he explicitly built with an export map). I haven't analyzed what is going on in this example though. The code is probably using some undefined behavior and getting zapped. -Chris > This function produces completely bogus code in LLVM, presumably because > some kind of LTO proves that CC1000SendReceiveP is never written. Of course, > this assumption would be wrong at runtime in a real program. > > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/015306.c > > Of course the answer is not to disable LTO, but rather to add an > "initializer" function that does > > volatile void *p; > memcpy (CC1000SendReceiveP__f, p, sizeof (CC1000SendReceiveP__f)); > memcpy (CC1000SendReceiveP__count, p, sizeof (CC1000SendReceiveP__count)); > memcpy (CC1000SendReceiveP__rxBuf, p, sizeof (CC1000SendReceiveP__rxBuf)); > > ... and to make all variables non-static (otherwise the initializer would > have to be in the same file, but that would perturb your results). > > I also agree with others that the frame pointer default is special enough to > warrant adding a special -f option to compilers that generate it, if some > other compilers do not generate it. > > Paolo >
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
On Mar 19, 2010, at 5:33 AM, b95705...@ntu.edu.tw wrote: > Hello Tristan, > >> I think the main issue is that EFI C dialect is not ANSI-C compliant: the >> size of pointer is determined >> at the run-time and therefore the layout of the structure is not static. >> Gcc doesn't support this model. > > As I read some related information, LLVM IR doesn't care the size of pointer > and the front end of LLVM is derived from GCC.I am wondering to know should > I do some work at this aspect?? FYI, the LLVM Clang front-end provides a C/ObjC and (real soon now) C++ compiler that is GCC-free. Further questions should definitely go to the llvm or clang lists. More information is at http://clang.llvm.org/ -Chris
Re: RFC: c++ diagnostics
On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote:
>
> Hello all!
>
> I've put up a short diagnostics comparison between gcc, icc, and
> clang. It is my plan to update this with major revisions to individual
> compilers.
>
> Included are most of the outstanding bugzilla requests with the
> "diagnostic" keyword. However, I am looking for help! Please send me
> code samples that frustrate, obfuscate, and annoy.
>
> In particular, I am looking for template instantiation issues such as
> c++/41884, but hopefully something in a deliciously small snippet. No
> doubt other C++ hackers have particular annoyances.
>
> I'm also looking for guidance on how to rank the priority of these
> issues. Is there some way to tell what the biggest annoyance is?
>
> http://people.redhat.com/bkoz/diagnostics/diagnostics.html
This is a great resource Benjamin, thanks for putting it together!
Some random thoughts if you ever regenerate this:
1) the caret diagnostics would be easier to understand in the output if
formatted with a or tag.
2) The clang invocations don't need -fcaret-diagnostics -fshow-source-location
-fdiagnostics-fixit-info because they are the default.
3) It's best to not pass -fdiagnostics-print-source-range-info unless you're
looking for machine interpretable output. This flag adds things like
{3:29-3:32} which are useful to a machine, but otherwise just clutter the
output up.
4) It looks like ICC defaults to a number of coding standards types of checks,
e.g. "access control not specified". I don't know if it is possible to turn
those off, but they seem to just be noise for the purposes of this comparison.
5) There are a couple cases of GCC rejecting valid code (e.g. 19377), or which
there may be some debate about (19538) it might be worth pointing this out.
*shrug*
6) My understanding was that GCC's complex extension in C++ mode is supposed to
work like C99 _Complex. If so, 41895 looks like a GCC bug. I don't know if
C++'0x affects this though.
7) There are some clang bugs here. Access control is not yet enabled by
default (affects 20397, 39728), and a variety of other bugs (affects 14283,
38612). I file Clang PR#6782/6783 to track these.
Thanks again for putting this together,
-Chris
Re: RFC: c++ diagnostics
On Apr 5, 2010, at 12:51 PM, Benjamin Kosnik wrote: >> >> 5) There are a couple cases of GCC rejecting valid code (e.g. 19377), >> or which there may be some debate about (19538) it might be worth >> pointing this out. *shrug* > > One of the goals was to measure the output when the input is > truncated, or obviously flawed (no semicolons is very > common!). Certainly if you can think of other (obvious) issues where > refactoring or haste make general classes of errors I'm very interested > in this particular type of pathology. Absolutely, this is one of the reasons I'm particularly interested in common errors like missing semi colons, . vs ->, use of things like <::foo>, explaining overload set failures, etc. > The valid code issues I can flag in the existing bug reports. Ok, thanks again. -Chris
Re: RFC: c++ diagnostics
On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote: > > Hello all! > > I've put up a short diagnostics comparison between gcc, icc, and > clang. It is my plan to update this with major revisions to individual > compilers. > > Included are most of the outstanding bugzilla requests with the > "diagnostic" keyword. However, I am looking for help! Please send me > code samples that frustrate, obfuscate, and annoy. > > In particular, I am looking for template instantiation issues such as > c++/41884, but hopefully something in a deliciously small snippet. No > doubt other C++ hackers have particular annoyances. > Hi Benjamin, I wrote a little blog post that shows off some of the things that Clang can do. It would be great to improve some of GCC/G++'s diagnostics in a similar way: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html -Chris
Re: RFC: c++ diagnostics
On Apr 6, 2010, at 9:29 AM, Manuel López-Ibáñez wrote: >> Hi Benjamin, >> >> I wrote a little blog post that shows off some of the things that Clang can >> do. It would be great to improve some of GCC/G++'s diagnostics in a similar >> way: >> >> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html > > Unfortunately, you mix C and C++ examples. I know it is because clang > parses both with the same parser but this thread is only discussing > improving C++ diagnostics in GCC, and there is no plan or project for > C diagnostics. As it happens, some C++ diagnostics are better than the > same diagnostic for C and viceversa. I think all the C examples are also valid C++ code, they should apply equally well, but I admit that I didn't try those on g++ to see how it does. I figured it also didn't matter much because there has surely been significant progress since gcc 4.2. -Chris
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Apr 11, 2010, at 5:54 AM, Dorit Nuzman wrote: > > * Get statistics on percentage of papers/projects that use compilers other > than GCC, and ask them why... Hi Dorit, Here is a semi reasonably list of llvm-based publications: http://llvm.org/pubs/ which might be useful. > (By the way, why was OpenCL implemented only on LLVM and not on GCC?) There are many reasons, but one of the biggest is the GCC doesn't (practically speaking) support JIT compilation. While it is possible to implement OpenCL on GCC, I suspect that the end result wouldn't be very compelling without some major architecture changes. -Chris
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Apr 11, 2010, at 12:05 PM, Grigori Fursin wrote: > By the way, I remember that when we had first discussions to include plugin > framework to GCC some > years ago, > first feedback was extremely negative. Nevertheless, GCC 4.5 will feature > plugin framework (that > will > also be very useful for research), so maybe GCC will support JIT compilation > too one day ;) ... Sure, I'm not saying that GCC won't make amazing infrastructure improvements, just explaining why opencl implementors didn't want to block on waiting for it to happen. > As for OpenCL and lack of JIT support in GCC, we have been effectively > overcoming this problem > for many years using static multi-versioning and run-time version selection > based on program > and system behavior (even though there are obvious limitations), > so I guess we can temporally continue using similar techniques for OpenCL in > GCC... I don't think that this is sufficient to implement OpenCL-the-spec well. You can definitely add support for opencl-the-kernel-language, but that's only half of OpenCL: the runtime, GPU integration, and OpenGL integration aspects are just as important. You can definitely implement all this by forking out to an assembler etc, the implementation will just not be great. -Chris
Re: Code assistance with GCC
On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote: > Hi, all > > I have been working on implementing a tool-set of code assistance called > GCCSense, which enables code-completion for C/C++ in editors or a terminal. > > http://cx4a.org/software/gccsense/ This approach seems highly, uh, "inspired" from the exact same functionality in Clang. Any reason not to contribute to that effort? -Chris
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
On Apr 21, 2010, at 9:53 AM, Vladimir Makarov wrote: > Only SPECIn2000 for x86_64 has been compiled fully successfully by > dragonegg. There were a few compiler crashes including some in LLVM > itself for SPECFP2000 and for SPECINT2000 for x86. > > So here is SPECInt2000 for x86_64 comparison: > > dragonegg: -O3 (with LLVM release build) > gcc4.5: -O3 -flto (--enable-checking=release) > > Compilation Time SPECINT2000 > Dragonegg 122.85user 2572 > gcc-4.5 283.49user 2841 > > On integer benchmarks, dragonegg generates about 11% slower code. > One interesting thing is that dragonegg is a really fast compiler. It > is 2.3 times faster than gcc. This is definitely interesting, but you're also comparing apples and oranges here (for both compile time and performance). Can you get numbers showing GCC -O3 and dragonegg with LTO to get a better comparison? -Chris
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
On Apr 21, 2010, at 11:11 AM, Vladimir Makarov wrote: >> >> This is definitely interesting, but you're also comparing apples and oranges >> here (for both compile time and performance). Can you get numbers showing >> GCC -O3 and dragonegg with LTO to get a better comparison? >> >> > Dragonegg does not work with -flto. It generates assembler code on which gas > complaints (a lot of non-assembler code like target data-layout which are not > in comments). Ok, I didn't know that didn't get wired up. I'm not familiar with dragonegg, it might require gold with the llvm lto gold plugin or something. > So I'll do gcc -O3 without -flto. I don't think it will change average > SPECINT2000 rate significantly (although it can change separte benchmark > significantly) but it will make gcc compiler much faster (may be 2 times > because I did not use -fwhole-program). I'll post the results in an hour. Sounds good, thanks! I suspect the gcc build times will improve. -Chris
Re: Code assistance with GCC
On Apr 21, 2010, at 1:51 PM, Manuel López-Ibáñez wrote: http://cx4a.org/software/gccsense/ >>> >>> This approach seems highly, uh, "inspired" from the exact same >>> functionality in Clang. Any reason not to contribute to that >>> effort? >> >> Surely trying to persuade people to contribute to some other project >> rather than gcc is off-topic here. Even if not, it's pretty hostile. > > Would such a feature be accepted in GCC? Otherwise, this seems like a > misunderstanding. Chris was not suggesting to contribute to Clang > instead of GCC but instead to contribute to the Clang completion > library rather than create your own 1-person project. Or at least this > is how I understood it. I actually meant to respond to him personally, I apologize for cc'ing the list. I did this because the other responses made it seem that it wasn't something that would be accepted back into GCC proper. Maintaining an invasive patch on the side for a long period of time didn't seem like a great idea. -Chris
Re: Code assistance with GCC
On Apr 22, 2010, at 4:29 AM, Jakub Jelinek wrote: >> >> I did this because the other responses made it seem that it wasn't >> something that would be accepted back into GCC proper. Maintaining an > > Can you point at any response that said it would not be accepted back into > GCC proper? There were no such comments AFAIK. All that has been said > is that it is not possible to implement it AS A PLUGIN, Nope, you are correct. Again, the cc was a mistake and I apologize for it. > at least not currently > and would probably require way too many hook points unless it wants to do > only code completion after . and -> (and not e.g. after :: and many other > tokens). For C++ tentative parsing is probably the biggest problem that > needs solving. I predict it won't be accepted into GCC mainline either, but we'll see. :) -Chris
Re: Why not contribute? (to GCC)
On Apr 23, 2010, at 5:05 PM, Basile Starynkevitch wrote: > Manuel López-Ibáñez wrote: >> On 24 April 2010 00:18, Alfred M. Szmidt wrote: >>> The disclaimers are legally necessary though, the FSF needs a paper >>> trail in the case your employer comes back and claims that they have >>> copyright over a change. >> BTW, in this aspect there is no difference between GCC and LLVM. The >> latter also requires to assign copyright to the University of >> Illinois. If you don't have a copyright disclaimer before contributing >> to LLVM, you are exposing yourself to some future legal troubles. > > The real issue is not the copyright disclaimer, it is the legal terms inside. > Maybe U.Illinois don't use words like "unlumited liaibility". > > But we cannot know for sure, these documents are not public. I'm not sure why you think that. Unlike the FSF, all of the LLVM projects' requirements are public: http://llvm.org/docs/DeveloperPolicy.html LLVM does not require a copyright assignment. People can send in random patches and they get immediately applied. -Chris
Re: Why not contribute? (to GCC)
On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote: > On 24 April 2010 00:18, Alfred M. Szmidt wrote: >> >> The disclaimers are legally necessary though, the FSF needs a paper >> trail in the case your employer comes back and claims that they have >> copyright over a change. > > BTW, in this aspect there is no difference between GCC and LLVM. The > latter also requires to assign copyright to the University of > Illinois. If you don't have a copyright disclaimer before contributing > to LLVM, you are exposing yourself to some future legal troubles. On what do you base these assertions? Every point seems wrong to me. -Chris
Re: Why not contribute? (to GCC)
On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote: > On 25 April 2010 06:20, Chris Lattner wrote: >> >> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote: >> >>> On 24 April 2010 00:18, Alfred M. Szmidt wrote: >>>> >>>> The disclaimers are legally necessary though, the FSF needs a paper >>>> trail in the case your employer comes back and claims that they have >>>> copyright over a change. >>> >>> BTW, in this aspect there is no difference between GCC and LLVM. The >>> latter also requires to assign copyright to the University of >>> Illinois. If you don't have a copyright disclaimer before contributing >>> to LLVM, you are exposing yourself to some future legal troubles. >> >> On what do you base these assertions? Every point seems wrong to me. > > Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted. -Chris
Re: Why not contribute? (to GCC)
On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote: On what do you base these assertions? Every point seems wrong to me. >>> >>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html >> >> The key distinction is that contributing to LLVM does not require you to >> sign a form (which isn't even publicly available) and mail it in to a busy >> and high-latency organization before non-trivial patches will be accepted. > > So, is the copyright disclaimer implicit in the patch submission? Who > defines the conditions? That web page is everything that there is. I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it. -Chris
Re: [lto][RFC] Do not emit hybrid object files
On Oct 17, 2008, at 1:01 PM, Jeff Law wrote: Reality is there aren't too many non-ELF targets that matter anymore and, IMHO, it's reasonable to demand ELF support for LTO. The only other format that has a reasonable chance of working would be the COFF variants anyway and the only COFF variant that is meaningful is used by AIX (and perhaps Darwin?!?). Darwin already has a GCC-based compiler that fully supports LTO, -Chris
LLVM 2.4
For anyone interested, LLVM 2.4 was just released: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-November/30.html http://llvm.org/releases/2.4/docs/ReleaseNotes.html It has a number of new features, but the most user visible one is that it compiles about 30% faster than LLVM 2.3 at "-O0 -g". This is a common mode for the compile/debug/edit turn around cycle and for various JIT applications. llvm-gcc was already typically 30% faster than GCC at compiling code when optimizations are enabled. Please see the release notes for more details, and follow up on the llvmdev mailing list if you have questions. -Chris
Re: Serious code generation/optimisation bug (I think)
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY writes:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means likely to work
on most compilers without exotic compile flags in 2009.
char *my_null_pointer;
char fn() { return *my_null_pointer; }
It will be quite a while before whole program optimization is good
enough to prove that my_null_pointer is not referenced by anything
else.
Perhaps in GCC, but this is not a good solution if you care about
other compilers.
-Chris
Re: Serious code generation/optimisation bug (I think)
On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
Chris Lattner writes:
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY writes:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means likely to work
on most compilers without exotic compile flags in 2009.
char *my_null_pointer;
char fn() { return *my_null_pointer; }
It will be quite a while before whole program optimization is good
enough to prove that my_null_pointer is not referenced by anything
else.
Perhaps in GCC, but this is not a good solution if you care about
other compilers.
Is LLVM smart enough to optimize that away, even when using shared
libraries?
Yes absolutely. Just build with -fvisibility-hidden or use an export
map to say that my_null_pointer is not exported. If it is static, it
will also do it at -O2. This is not even a particularly aggressive
optimization.
-Chris
Re: Request for testing/help for the LTO branch
On Jan 27, 2009, at 1:11 PM, Diego Novillo wrote: The LTO branch is starting to get some semblance of stability, though is by no means in any kind of mergeable state. I have updated the wiki page to reflect the current status (Simon, Rafael, Doug, Cary, please make sure I haven't missed anything substantial): http://gcc.gnu.org/wiki/LinkTimeOptimization Hi Diego, Thanks for the summary, it's great to see the progress of the project. Do you have any compile time numbers for LTO so far? If you pick a mid-sided program from spec or even a bootstrap, how much slower is LTO than compiling at -O3? -Chris
Re: Serious code generation/optimisation bug (I think)
On Jan 27, 2009, at 10:47 PM, Ian Lance Taylor wrote: Is LLVM smart enough to optimize that away, even when using shared libraries? Yes absolutely. Just build with -fvisibility-hidden or use an export map to say that my_null_pointer is not exported. If it is static, it will also do it at -O2. This is not even a particularly aggressive optimization. Sure, but the whole idea here is for the compiler to *not* know that the pointer has a zero value. What I was really asking was whether LLVM would figure that out without taking any special action to restrict the visibility of the pointer. I don't think that there is any smartness in assuming that. I would claim that would be outrageously unsafe and incorrect to do that, unless the optimization is done at runtime or the user provides a flag with -fwhole-program. Regardless, many people build their libraries with -fvisibility-hidden, and build settings are often not controlled by engineers hacking code. It would be fragile to assume these aren't being set. Laurent originally asked for a safe idiom for doing this "likely to work on most compilers without exotic compile flags in 2009". The idiom won't work, because many compilers other than LLVM default to whole-program optimization at sufficiently high -O levels, and you presumably don't want to make fragile assumptions about what *other* flags are getting passed to your build. He said nothing about libraries or where the code may end up. I'm pretty sure that shared libraries are rare on systems without mmu's anyway. -Chris
Re: RFC: case insensitive for #include
On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote: Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? I strongly recommend against this, unless this is only a "last chance" fall back. From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you don't want to stat all variants of "foo.h" in dir1 before moving on to dir2. If you do a full search for foo.h in all appropriate search paths, and then redo it only on failure, then the performance issue goes away. However, in that case you get very difficult to explain behavior if you have multiple files with spelling variants of foo.h in different search paths. -Chris
Re: New GCC Runtime Library Exception
On Jan 29, 2009, at 7:38 AM, Joern Rennecke wrote: > The difference is that the front end does not work on source code, but > Java bytecode, which seems closer to intermediate representation than > to a "high-level, non-intermediate language". I think it is clear that Java bytecode, which can even be executed directly by some microprocessors, is not a "compiler intermediate representation." That is beside the point. It is not a high level language. Hence, when you use gcc to compile Java bytecode to Target Code, this is not an eligible compilation process. When you use a non-GPL-compatible java frontend to compile Java source to bytecode and then use GCC to compile this to Target Code, it is not an eligble compilation process either, because you used a non-GPL- compatible frontend. This issue is also somewhat confusing to me. It is a moot point, because LLVM is GPL compatible, but is LLVM .ll language considered a target code, intermediate representation, or a "high-level, non- intermediate language"? It is not clear to me how LLVM .ll files are different from .c files that are used as intermediates between bison and a C compiler. LLVM .ll files are a fully documented language and people write them by hand all the time. It is quite arguably much higher level that machine code (having concepts like "call with arguments", a type system, etc), and is fully specified (http://llvm.org/docs/ LangRef.html). It seems quite possible to argue that it is a "high- level, non-intermediate language" (at least at least as much as C is). Is the wording intended to allow LLVM .ll files as "high-level, non- intermediate language", or are they considered an IR? What is the dividing line? It seems that this is a very important issue for the entire license. -Chris
Re: RFC: case insensitive for #include
On Jan 28, 2009, at 12:24 PM, H.J. Lu wrote: On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner wrote: On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote: Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? I strongly recommend against this, unless this is only a "last chance" fall back. From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you don't want to stat all variants of "foo.h" in dir1 before moving on to dir2. If you do a full search for foo.h in all appropriate search paths, and then redo it only on failure, then the performance issue goes away. However, in that case you get very difficult to explain behavior if you have multiple files with spelling variants of foo.h in different search paths. I won't stat all variants of "foo.h". I think scandir will work here and this feature will be supported only if scandir is available. HJ, this is a very performance sensitive part of the preprocessor. Just doing a scandir would be a huge cost. -Chris
Re: Request for testing/help for the LTO branch
On Jan 29, 2009, at 11:25 AM, Rafael Espindola wrote: Is it IO bound because the LTO files are abnormally large? What kinds of file sizes are you seeing? With the streamer debug enable we had over 40x the normal object size. Without it, it looks to be 4 or 5 times if I remember correctly. Thanks Rafael! -Chris
