Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
> > for this specific function (vrp_int_const_binop), I'm issuing a > > warning inside the else-if branch that tests for the overflowed > > result. I'm unclear why that is a false positive since the result is > > known to overflow. Could you elaborate? > > Well, we use that function to do arithmetic on value ranges like > for example the ranges involving the expression a + b > > [50, INT_MAX] + [50, 100] > > now you will get a warning as we use vrp_int_const_binop to add > INT_MAX and 100 (to yield INT_MAX in the signed case). Of > course adding a + b will not always overflow here (it might never > as the INT_MAX bound might be just due to VRP deficiencies), > for example 50 + 50 will not overflow. > > So using vrp_int_const_binop to generate the warning will yield > very many false positives (also due to the fact that if we only know > the lower or upper bound we have lots of INT_MAX and INT_MIN > in value ranges). You could emit a warning if the entire range overflows (i.e. both lower and upper bound calculations overflow), since that means that the calculation of a+b necessarily overflows. Best wishes, Duncan.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
On Sunday 31 December 2006 16:19, Richard Kenner wrote:
> > If done in unsigned, this won't lead to any optimization, as unsigned
> > arithmetic doesn't have overflows. So, if you write "a - 10" where a
> > is unsigned, the compiler can't assume anything, whereas is a is
> > signed, the compiler can assume that a >= INT_MIN + 10, reducing
> > the range for a, and possibly allowing some optimizations.
>
> I don't follow. The purpose of this hand-optimization (whch is also done
> by GCC) is to replace two comparisons with one subtraction and one
> comparison, which is faster on most machines. It's not CORRECT to do this
> transformation in signed unless you know there won't be overflow.
>
> In general, for modern compilers it's best not to do this transformation
> AT ALL and let the compiler figure out the best way to do the range tst.
Funny you should say that, because the Ada front-end likes to do this
transformation, rather than leaving it to the back-end. For example:
procedure P (X : Natural) is
subtype Y is Natural range 10 .. 20;
begin
if X in Y then
raise Program_Error;
end if;
end;
turns into
P (x)
{
typedef p__y___XDLU_10__20 p__y___XDLU_10__20;
typedef p__y___XDLU_10__20 p__y___XDLU_10__20;
if ((unsigned int) ((integer) x - 10) <= 10)
{
__gnat_rcheck_17 ("p.adb", 5);
}
else
{
}
return;
}
The C front-end performs this transformation too. I'm not claiming that the
back-end optimizers would actually do something sensible if the front-end
didn't transform this code (in fact they don't seem too), but since the
optimal way of doing the check presumably depends on the target, wouldn't
it make sense if the backend took care of it?
Best wishes,
Duncan.
Re: Scheduling
> Please does anyone know the answer to the following questions? > > 1. The operating system (OS) schedules tasks, but gnat allow us to set > schedule policies such as Round Robin, then how does gnat tell the OS to > start doing Round Robin scheduling? > > 2. If someone wants to write a new scheduling policy, what files I need to > add and update to tell gnat to use my scheduling policy. > > For example, if I want tasks to block, even though it does NOT want to use a > shared data object, but if another task on the "same" cpu is running and is > using a shared data object that other tasks on other CPUs need that shared > data object. > > For example, I see for Round Robin, gnat has the following files: > a-diroro.ads and a-diroro.adb > > 3. Which gnat files for tasking and scheduling tell the tasks to use these > files and how these files hookup to the tasking model? > > 4. What gnat file is the Scheduling and Tasking file? I want to see how it > uses the Round Robin or how scheduling works in gnat? I suggest you try asking on comp.lang.ada. Best wishes, Duncan.
Re: Miscompilation of remainder expressions
On Tuesday 16 January 2007 16:50, Andrew Haley wrote: > Roberto Bagnara writes: > > Andrew Haley wrote: > > > Roberto Bagnara writes: > > > > > > > > Reading the thread "Autoconf manual's coverage of signed integer > > > > overflow & portability" I was horrified to discover about GCC's > > > > miscompilation of the remainder expression that causes INT_MIN % -1 > > > > to cause a SIGFPE on CPUs of the i386 family. Are there plans to > > > > fix this bug (which, to me, looks quite serious)? > > > > > > No, there aren't. It would make more sense for you to wrap % in some > > > code that checks for this, rather than for us to slow down every division > > > for this one special case. > > > > With all due respect, I must say I am shocked. I always thought > > (and taught) that we, Free Software people, value standard conformance > > and getting things right. > > This is a disgreement about interpretation of the langauge in the > standard, which is: > > "The result of the / operator is the quotient from the division of the > first operand by the second; the result of the % operator is the > remainder. In both operations, if the value of the second operand is > zero, the behavior is undefined. When integers are divided, the result > of the / operator is the algebraic quotient with any fractional part > discarded.87) If the quotient a/b is representable, the expression > (a/b)*b + a%b shall equal a." > > If the quotient a/b is *not* representable, is the behaviour of % > well-defined or not? It doesn't say. In ada/exp_ch4.adb you will find: -- Deal with annoying case of largest negative number remainder -- minus one. Gigi does not handle this case correctly, because -- it generates a divide instruction which may trap in this case. -- In fact the check is quite easy, if the right operand is -1, -- then the mod value is always 0, and we can just ignore the -- left operand completely in this case. Ada semantics require INT_MIN rem -1 to be zero. Best wishes, Duncan.
Re: what is difference between gcc-ada and GNAT????
Hi Sameer Sinha, > can any one tell me what is the difference between gcc-ada and > differnt other compiler for Ada 95 like GNAT GPL, GNAT Pro, > what is procedure to build only language Ada by using source code og > gcc-4.1??? they are closely related. There are two groups: (1) versions released by ACT (http://www.gnat.com): GNAT GPL and GNAT Pro. (2) versions released by the FSF (http://gcc.gnu.org): gcc-4.1 etc GNAT Pro is ACT's commercial offering: you have to have a support contract with them to get it. GNAT GPL is basically the same compiler, but it is unsupported, and the license has been changed so that software built with and distributed to the world has to be under the GPL license to be legal (at least, that seems to be the intention). The FSF compiler is freely available and doesn't have the license restrictions of the GNAT GPL. The technical differences between the compilers are basically in the code generators: the ACT compilers use a modified code generator from gcc 3.4.6. The FSF compilers use more recent and quite different code generators. However the ACT compilers tend to be more stable than the FSF ones, because the FSF code generators and the Ada front-end do not yet interact perfectly. I understand that the next releases of GNAT GPL and GNAT Pro will be based on the same code generator as the FSF compilers, at which point the difference between the FSF and ACT offerings will doubtless be much less. Best wishes, Duncan.
Re: what is difference between gcc-ada and GNAT????
> So we are in better shape than implied above. We have quite > a reasonable set of stability and regression tests for the > Ada front end. Given the restrictions on proprietary code > use, this is about as good as we can do for now. Of course > it is valuable if people submit more tests to this test suite. Couldn't you pass proprietary code through an obfuscator? Duncan.
Re: what is difference between gcc-ada and GNAT????
> But Duncan, you were generating a bunch of proprietary > Ada code recently, if you can get people to be comfortable > submitting it, possibly in obfuscated form, by all means > go ahead! I already started doing this, see http://gcc.gnu.org/ml/gcc/2006-07/msg00591.html Duncan.
Re: Fold and integer types with sub-ranges
> Currently for example in fold_sign_changed_comparison we produce > integer constants that are not inside the range of its type values > denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example > consider a type with range [10, 20] and the comparison created by > the Ada frontend: > > if ((signed char)t == -128) > > t being of that type [10, 20] with TYPE_PRECISION 8, like the constant > -128. So fold_sign_changed_comparison comes along and decides to strip > the conversion and convert the constant to type T which looks like ... > What do we want to do about that? Do we want to do anything about it? > If we don't want to do anything about it, why care about an exact > TREE_TYPE of integer constants if the only thing that matters is > signedness and type precision? I don't think gcc should be converting anything to a type like t's unless it can prove that the thing it's converting is in the range of t's type. So it presumably should try to prove: (1) that -128 is not in the range of t's type; if it's not, then fold the comparison to false; otherwise (2) try to prove that -128 is in the range of t's type; if so, convert it. Otherwise do nothing. That said, this whole thing is a can of worms. Suppose the compiler wants to calculate t+1. Of course you do something like this: int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0); But if 1 is not in the type of t, you just created an invalid value! Personally I think the right thing to do is to eliminate these types altogether somewhere early on, replacing them with their base types (which don't have funky ranges), inserting appropriate ASSERT_EXPRs instead. Probably types like t should never be seen outside the Ada f-e at all. Ciao, Duncan.
Re: Fold and integer types with sub-ranges
On Saturday 24 February 2007 14:27:36 Richard Kenner wrote: > > Sure - I wonder if there is a reliable way of testing whether we face > > a non-base type in the middle-end. I suppose TREE_TYPE (type) != NULL > > won't work in all cases... (?) > > That's the right way as far as I know. Note that having TREE_TYPE(type)!=NULL does not imply that the type and the base type are inequivalent. For example, if you declare a type Int as follows: subtype Int is Integer; then TREE_TYPE(type_for_Int)=type_for_Integer, but the types are equivalent, in particular they have the same TYPE_MIN_VALUE and TYPE_MAX_VALUE. Ciao, Duncan.
Re: What tells the coding style about whitespaces at end of lines or in *empty* lines ?
> > I noticed while editing gcc files, that there are a lot of *useless* > > whitespaces at the end of lines or within empty lines, which are getting > > automatic removed by some *smarter* editors as I am common to use *sigh*. > > This leads to huge diff files and the real change is getting veiled. I > > think it would be nice to eliminate these *usesless* whitespaces. > > Note that the coding standard for GNAT forbids trailing white spaces. > It also forbids embedded horizontal tabs for similar reasons (avoiding > junk difs). And the compiler enforces this, which is an important point. Duncan.
Re: Static Chain Argument in call_expr
> in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the
> static chain argument, or NULL. Can someone tell me or reference me to
> what static chain argument is?
It's for nested functions, eg
int parent (int n)
{
int child (int m) { return m * n; }
return child (2);
}
Notice how child using a variable of parent, namely
the parameter n. This gets lowered to something like:
struct frame { int n; };
int child (struct frame *static_chain, int m) { return m * static_chain->n; }
int parent (int n)
{
struct frame FRAME;
FRAME.n = n;
return child (&FRAME, 2);
}
Ciao,
Duncan.
Re: __builtin_cpow((0,0),(0,0))
On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote: > Paolo Carlini wrote: > > Andrew Haley wrote: > > > >> F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN. > >> > >> > > Indeed. My point, basically, is that consistency appear to require the > > very same behavior for *complex* zero^zero. > > I am not sure, it looks like the standard is deliberately vague here, > and is not requiring this result. Mathematically speaking zero^zero is undefined, so it should be NaN. This already clear for real numbers: consider x^0 where x decreases to zero. This is always 1, so you could deduce that 0^0 should be 1. However, consider 0^x where x decreases to zero. This is always 0, so you could deduce that 0^0 should be 0. In fact the limit of x^y where x and y decrease to 0 does not exist, even if you exclude the degenerate cases where x=0 or y=0. This is why there is no reasonable mathematical value for 0^0. Ciao, Duncan.
Re: __builtin_cpow((0,0),(0,0))
Hi Chris,
> | Mathematically speaking zero^zero is undefined, so it should be NaN.
> | This already clear for real numbers: consider x^0 where x decreases
> | to zero. This is always 1, so you could deduce that 0^0 should be 1.
> | However, consider 0^x where x decreases to zero. This is always 0, so
> | you could deduce that 0^0 should be 0. In fact the limit of x^y
> | where x and y decrease to 0 does not exist, even if you exclude the
> | degenerate cases where x=0 or y=0. This is why there is no reasonable
> | mathematical value for 0^0.
> |
>
> That is true.
>
> However, on the other hand, however the standard says looks to me to say
> 0^0=1. Also printf("%f",pow(0.0,0.0)) returns 1.0 on both VC++6 and g++
> 3.3 (just what I happen to have lying around..)
>
> I would agree with Paolo that the most imporant point is arguably
> consistency, and it looks like that is pow(0.0,0.0)=1
just so long as everyone understands that they are upholding the
standard, not mathematics, then that is fine by me :)
All the best,
Duncan.
PS: There is always the question of which standard is being upheld,
since presumably both the Fortran and Ada standards have something
to say about this.
Re: __builtin_cpow((0,0),(0,0))
Hi Robert, > > It's not true because it's neither true nor false. It's a not well > > formulated statement. (Mathematically). > > I disagree with this, we certainly agree that 0.0 ** negative value > is undefined, i.e. that this is outside the domain of the ** function, > and I think normally in mathematics one would say the same thing, > and simply say that 0**0 is outside the domain of the function. > > However, we indeed extend domains for convenience. After all > typically on computers 1.0/0.0 yielding infinity, and that > certainly does not correspond to the behavior of the division > operator over the reals in mathematics, but it is convenient :-) the problem with 1.0/0.0 is not so much the domain but the range: it is the range which needs to be extended to contain an infinite value (representing both + and - infinity), at which point the definition 1.0/0.0 = infinity is an example of the standard notion of "extension by continuity". The problem with x^y is that the range of limits as (x,y) converges to zero (through x>0,y>0) is the entire interval of real numbers between 0 and 1 inclusive. Attempts to extend by continuity are doomed in this case (the fact that the limiting values also arise as values of x^y for x,y>0 means that attempts to "fix up" the range bork the usual function meaning). Ciao, Duncan.
Re: __builtin_cpow((0,0),(0,0))
Hi Florian, > From a mathematical point of view, 0^0 = 1 is the more convenient one > in most contexts. Otherwise, you suddenly lack a compact notation of > polynomials (and power series). However, this definition is only used > in a context were the exponent is an integer, so it's not really > relevant to the current discussion. if you restrict the domain of x^y to: x>=0 (real), y an integer >=0, and (x,y) not equal to zero, then there is a unique limit as (x,y) converges to zero, namely 1. So this is an example of extending by continuity. Ciao, Duncan.
Re: [OT] __builtin_cpow((0,0),(0,0))
Hi Paolo, > > What we are debating here isn't really maths at all, just the > > definition which will be most useful and least suprising (and perhaps > > also what various standards tell us to use). > > Also, since we are definitely striving to consistently implement the > current C99 and C++ Standards, it's *totally* pointless discussing 0^0 > in the real domain: it *must* be one. Please, people, don't overflow the > gcc development list with this kind of discussion. I feel guilty because > of that, by the way: please, accept my apologies. My original question > was *only* about consistency between the real case (pow) and the complex > case (cpow, __builtin_cpow, std::complex::pow). aren't __builtin_cpow and friends language independent? I mean, if a front-end sees a x^y then presumably it ends up being turned into a call to a __builtin_?pow by the back-end. If so, then conforming to the C99 and C++ standards isn't enough: the standards for all gcc supported languages need to be checked. Since some of them require one, as long as none of the others requires something else then it is clear that one should be returned. But do any other languages require something else? All the best, Duncan.
Re: [OT] __builtin_cpow((0,0),(0,0))
Hi Robert, > Well if you tell me there are people about there implementing cpow > with log and exp, that's enough for me to decide that Ada should > continue to stay away (the Ada RM has accuracy requirements that > would preclude a broken implementation of this kind) :-) the reference manual allows for a "relaxed mode", which doesn't have those accuracy requirements. I guess -ffast-math and the use of builtins would be appropriate in the relaxed mode. Do you plan to implement such a mode one day? Just curious. All the best, Duncan.
Re: [OT] __builtin_cpow((0,0),(0,0))
Hi Robert, > >>Well if you tell me there are people about there implementing cpow > >>with log and exp, that's enough for me to decide that Ada should > >>continue to stay away (the Ada RM has accuracy requirements that > >>would preclude a broken implementation of this kind) :-) > > > > > > the reference manual allows for a "relaxed mode", which doesn't have > > those accuracy requirements. I guess -ffast-math and the use of > > builtins would be appropriate in the relaxed mode. Do you plan to > > implement such a mode one day? > > > > Just curious. > > > > All the best, > > > > Duncan. > > No plans, but also note that the use of log/exp for ** besides > being horribly inaccurate, is also inefficient. Fast accurate > math is achievable, we don't see a need for a relaxed mode. if the Ada front-end has an efficient, accurate implementation of x^y, wouldn't it make sense to move it to the back-end (__builtin_pow) so everyone can benefit? Ciao, Duncan.
Re: __builtin_cpow((0,0),(0,0))
> On the one hand, as said above, there is no way of defining 0^0 > using continuity, but on the other hand, many important properties > remain satisfied if we choose 0^0 = 1 (which is frequently > adopted, as a convention, by mathematicians). Kahan suggests to > choose 0^0 = 1. [...] The problem is x^0.0 (real exponent), not x^0 (integer exponent). 0^0 (integer exponent) *can* be defined by continuity, the value is 1. The fact that it is defined by continuity is exactly the reason 0^0=1 is useful in contexts where the exponent is an integer (polynomials etc): the special case 0^0 acts the same as the general case x^0, since it is the limiting value of it. In my experience, defining 0^0.0 (real exponent) to be 1.0 is much less useful. Now in practice I can imagine that a language confuses x^integer and x^real by mapping them to the same function, or only provides a function for doing x^real. Perhaps this is the case with C? If so, then having 0^0.0 return 1.0 is a convenient hack to work around that mistake. On the other hand, ignoring such things as language standards and the weight of history, if there are separate functions for x^integer and x^real, then in my opinion the most sensible thing would be for 0^0 to return 1, and 0^0.0 to return NaN. This might confuse programmers though. All the best, Duncan.
Re: Heads-up: volatile and C++
On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote:
> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote:
> > [Ada standard]
>
> Yep, sounds a lot like C/C++: volatile reads and writes are required to
> have sequential ordering relative to each other, but (outside the current
> thread) they are not ordered relative to non-volatile reads and writes.
Here's an extract from section 9.10 ("sequential"):
15.a
Ramification: If two actions are ``sequential'' it is known that their
executions
don't overlap in time, but it is not necessarily specified which occurs first.
For
example, all actions of a single task are sequential, even though the exact
order
of execution is not fully specified for all constructs.
15.b
Discussion: Note that if two assignments to the same variable are sequential,
but
neither signals the other, then the program is not erroneous, but it is not
specified
which assignment ultimately prevails. Such a situation usually corresponds to a
programming mistake, but in some (rare) cases, the order makes no difference,
and for
this reason this situation is not considered erroneous nor even a bounded
error. In
Ada 83, this was considered an ``incorrect order dependence'' if the ``effect''
of the
program was affected, but ``effect'' was never fully defined. In Ada 95, this
situation
represents a potential nonportability, and a friendly compiler might want to
warn the
programmer about the situation, but it is not considered an error. An example
where
this would come up would be in gathering statistics as part of referencing some
information, where the assignments associated with statistics gathering don't
need to
be ordered since they are just accumulating aggregate counts, sums, products,
etc.
Ciao,
Duncan.
Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?
Hi David, It looks strange to me that this repository contains these per-gcc -version auto-generated .inc files; aren't these something that should just be created at build time? IIRC I did it this way because to generate these files you need to have the entire GCC sources, while one of the goals of dragonegg was that in order to be able to build dragonegg you should only need to have the gcc headers installed. Best wishes, Duncan.
Re: pass 'lto_gimple_out' not found, how to migrate it for GCC v6.x?
Hi, It says // Disable all LTO passes. (for whatever reason). So try just removing this part - the pass is already removed. IIRC it disables passes that run after gimple has been converted to LLVM IR, as running them would just consume time pointlessly. Best wishes, Duncan.
Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets
Hi Vladimir, thanks for doing this. The above said about compilation speed is true when GCC front-end is used for LLVM. It's not clear to me which GCC front-end you mean. There is llvm-gcc (based on gcc-4.2) and the dragonegg plugin (the 2.9 version works with gcc-4.5; the development version works also with gcc-4.6). Can you please clarify. By the way, some highly unscientific experiments I did suggest that the GCC tree optimizers are (almost) as fast as the LLVM IR optimizers while doing a better job; while at -O3 the LLVM code generators are significantly faster than the GCC code generators and do a comparable and sometimes better job. Unfortunately I haven't had time to do a serious study, so this might just be an accident of the benchmarks I looked at and the options I happened to use rather than anything meaningful. Ciao, Duncan.
Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets
On 07/09/11 17:55, Xinliang David Li wrote: Why is lto/whole program mode not used in LLVM for peak performance comparison? (of course, peak performance should really use FDO..) Assuming Vladimir was using the dragonegg plugin: presumably because it's a pain: you have to compile everything to assembler (-S) rather than to an object file (-c). That's because -flto outputs LLVM IR when used with this plugin, and the system assembler doesn't understand it (and GCC insists on sending output to the system assembler if you pass -c). You then have to convert each .s into a .o (or .bc) using llvm-as. At that point if you have the gold linker and the LLVM linker plugin you can just link using them and you are done. Ciao, Duncan. thanks, David On Wed, Sep 7, 2011 at 8:15 AM, Vladimir Makarov wrote: Some people asked me to do comparison of GCC-4.6 and LLVM-2.9 (both released this spring) as I did GCC-LLVM comparison in previous year. You can find it on http://vmakarov.fedorapeople.org/spec under 2011 GCC-LLVM comparison tab entry. This year the comparison is done on GCC 4.6 and LLVM 2.9 which were released in spring 2011. As usually I am focused mostly on the compiler comparison as *optimizing* compilers on major platform x86/x86-64. I don't consider other aspects of the compilers as quality of debug information, supported languages, standards and extensions (e.g. OMP), supported targets and ABI, support of just-in-time compilation etc. Different to the 2010 comparison, the SPEC2000 benchmarks were run on a recent *Sandy Bridge processor* which will be a mainstream processor at least for the next year. This year I tried to decrease the number of graphs which are still too many with my point of view. Some graphs are bigger than for 2010 comparison and oriented to screens with a larger resolution. If you need exact numbers you should look at the tables from which the graphs were generated. I added GCC run with -O1 which helps to understand that *LLVM with -O2 or -O3 is analog of GCC 4.1 with -O1 with the point of view of generated code performance and compilation speed*. People are frequently saying that LLVM is a much faster compiler than GCC. That is probably not true. If you need the same generated code quality and compilation speed as LLVM -O2/-O3 you should use GCC with -O1. If you want 10%-40% faster generated code, you should use GCC with -O2/-O3 and you need 20%-40% (150%-200% if you use GCC LTO) more time for compilation. I believe that LLVM code performance is far away from GCC because it is sufficiently easy to get first percents of code improvement, it becomes much harder to get subsequent percents, and IMHO starting with some point of the development the relation of the code improvement to the spent efforts might become exponential. So there is no magic -- GCC has a better performance because much more efforts of experienced compiler developers have been spent and are being spent for GCC development than for LLVM. The above said about compilation speed is true when GCC front-end is used for LLVM. LLVM has another C-language family front-end called CLANG which can speed up compilation in optimization mode (-O2/-O3) upto 20%-25%. So even as LLVM optimizations are not faster than GCC optimizations, CLANG front-end is really faster than GCC-frontend. I think GCC community should pay more attention to this fact. Fortunately, a few new GCC projects address to this problem and I hope this problem will be solved or alleviated. This year I used -Ofast -flto -fwhole-program instead of -O3 for GCC and -O3 -ffast-math for LLVM for comparison of peak performance. I could improve GCC performance even more by using other GCC possibilities (like support of AVX insns, Graphite optimizations and even some experimental stuff like LIPO) but I wanted to give LLVM some chances too. Probably an experienced user in LLVM could improve LLVM performance too. So I think it is a fair comparison.
Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets
Why is lto/whole program mode not used in LLVM for peak performance comparison? (of course, peak performance should really use FDO..) Thanks for the feedback. I did not manage to use LTO for LLVM as it described on http://llvm.org/docs/LinkTimeOptimization.html#lto I am getting 'file not recognized: File format not recognized' during the linkage pass. Note that these are the instructions to follow on linux for LTO with llvm-gcc: http://llvm.org/docs/GoldPlugin.html Ciao, Duncan. You probably right that I should use -Ofast without -flto for gcc then. Although I don't think that it significantly change GCC peak performance. Still I am going to run SPEC2000 without -flto and post the data (probably on the next week). Note that due to a bug in 4.6.x -Ofast is not equivalent to -O3 -ffast-math (it doesn't use crtfastmath.o). I'll backport the fix. As for FDO, unfortunately for some tests SPEC uses different training sets and it gives sometimes wrong info for the further optimizations. I do not look at this comparison as finished work and am going to run more SPEC2000 tests and change the results if I have serious reasonable objections for the current comparison.
Re: adding destroyable objects into Ggc
Hi Basile, I would like to add destroyable objects into Ggc (the GCC garbage collector, see files gcc/ggc*.[ch]). The main motivation is to permit C++ objects to be garbage collected (I discussed that briefly in the Gcc meeting at Google in London): adding destroyable object is a prerequisite for that goal. it is already possible to have garbage collected C++ objects with destructors. I use this in the dragonegg plugin (see the file Cache.cpp). I do only use htab's though, which comes with support for destructors. After allocating the garbage collected memory, I construct the object using placement new. The memory is allocated using htab_create_ggc, the last argument of which is a destructor function which in my case does a call to the objects destructor. Ciao, Duncan.
Re: adding destroyable objects into Ggc
Hi Gabriel, I also agree with you that GCC architecture is messy, and that scares newscomer a lot. Yes, but the way we improve it isn't, in my opinion, adding more GC. First we would like to remove complexity, and I do not think we should start by focusing on storage management until we get a clearer idea about lifetime of data structures we manipulate and how they mesh. We might find out (as I suspect) that the builtin GC of C (or C++) is remarkable at the job, provided we have a design that makes the lifetime obvious and take advantage of it. what you say sounds very sensible to me. If you look at LLVM, most memory management is done by using container objects (vectors, maps etc) that automatically free memory when they go out of scope. This takes care of 99% of memory management in a clean and simple way, which is a great situation to be in. Ciao, Duncan.
Re: adding destroyable objects into Ggc
Hi Basile, But I don't understand how Ggc could be avoided (and I am not sure to understand how even LLVM can avoid any kind of garbage collection in the long run). I doubt LLVM will ever need garbage collection, because the way it is designed makes memory management easy. I already mentioned the use of containers, but of course containers can't handle everything. So consider a typical thing you might want to do: replace an instruction I1 by a different one I2 (for example because you understood that I1 simplifies to the simpler instruction I2) and delete I1. You can think of an LLVM instruction as being a gimple statement. One of the design points of LLVM is that instructions always know about all users of the instruction (def-use chains are built in). Thus you can do I1->replaceAllUsesWith(I2); and at this point everything using I1 as an operand now uses I2 instead. Thus the only place still referring to I1 is the function that the instruction I1 is linked into. You can unlink it and free the memory for I1 as follows I1->eraseFromParent(); And that's it. The price you pay for this simplicity is the need to keep track of uses - and this does cost compilation time (clear to anyone who does some profiling of LLVM) but it isn't that big. The big advantage is that memory management is easy - so easy that I suspect many LLVM users never thought about the design choices (and trade-offs) that make it possible. Ciao, Duncan. PS: You may wonder about copies of I1 cached in a map or whatnot, where it can be tricky (eg breaks an abstraction) or expensive to flush I1 from the data structure. This situation is handled conveniently by an extension of the above mechanism where in essence your copy of I1 in the data structure can register itself as an additional user of I1. When I1 is replaced by I2 then (according to how you chose to set things up) either the copy in the data structure gets turned into I2, or nulled out, or a special action of your choice is performed.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Ciao, Duncan. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&revision=5169&root=starpu&pathrev=5202 The macro is fairly elaborate. Yet, ICC 12.0.1 and Clang 3.4 both pass the test, because: - They support ‘--version’; - They define ‘__GNUC__’, which defeats Autoconf’s ‘_AC_LANG_COMPILER_GNU’. - They support ‘-print-file-name’, and have ‘-print-file-name=plugin’ return GCC’s (!) plug-in header directory. To that end, ICC simply runs ‘gcc -print-file-name=plugin’, while Clang appears to be doing some guesswork. It turns out that ICC manages to build a working GCC plug-in, so after all, it may be “entitled” to define ‘__GNUC__’, in a broad sense. Conversely, Clang doesn’t support several GNU extensions, such as nested functions, so it quickly fails to compile code. Based on that, I modified my feature test like this: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?), but I wanted to document this state of affairs. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, I didn't really get it. Why do you want to know whether the compiler is GCC or not? Presumably because you have several versions of your code, one version using GCC feature XYZ and the other not using XYZ. If so, the logically correct (but maybe impractical) approach is to test if the compiler supports XYZ, and switch between the two code versions depending on that. For example if XYZ is "nested functions", do you have a version of your code that uses nested functions and another that does not? If you don't have a version that works with compilers like clang that don't support nested functions, then why bother testing for nested function support? You will discover the lack of nested function support when your code fails to compile. Ciao, Duncan. On 19/01/12 15:39, Ludovic Courtès wrote: Hi Ducan, Duncan Sands skribis: A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Yes. The macro I posted is a feature test: it tests for plug-in header availability, and the availability of several GCC internal types and declarations. When I noticed that Clang doesn’t support nested functions, I added that to the test: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 Yet, I can’t reasonably add a feature test for each GNU extension that GCC’s headers or my own code use. Maybe tomorrow Clang will support nested functions, while still lacking support for some other extension that’s needed. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo,
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__)&& !defined(__ICC)&& !defined(__cplusplus)
Yeah, but it’s a shame that those compilers define __GNUC__ without
supporting 100% of the GNU C extensions. With this approach, you would
also need to add !defined for Clang, PGI, and probably others.
even GCC may not support 100% of the GCC extensions! For example, you can
find hacked GCC's out there which disable nested function support by default
(I think Apple did this). Even more problematic IMO than testing __GNUC__ is
code that tests for particular versions of GCC. There are versions of GCC
which have backported features from more recent GCC's (eg: GNAT from Ada Core
Technologies is like this). I've seen this cause problems with code that
includes different header files depending on the gcc version, since the
compiler doesn't have the expected set of header files.
Ciao, Duncan.
Re: Dealing with compilers that pretend to be GCC
On 24/01/12 17:32, Joseph S. Myers wrote: On Thu, 19 Jan 2012, Ludovic Court�s wrote: It turns out that ICC manages to build a working GCC plug-in, so after I would say there is some conceptual confusion here (based on this sentence, without having looked at the autoconf macros you refer to). Logically there are two or three different compilers involved: * The compiler (host-x-target) into which a plugin would be loaded. This is the one that needs to be GCC. * The compiler (build-x-host) building the plugin. There is no particular reason it should need to be GCC, if sufficiently compatible with the compiler that built the host-x-target compiler that will load the plugin. Users of the dragonegg plugin (what few there are!) are often confused by this, thinking that they need to build the plugin with the compiler into which the plugin is going to be loaded, which of course is not the case. In fact if the target compiler (host-x-target) is a cross-compiler, for example running on x86 and producing code for ppc, there is no way it can be used to compile the plugin, since that needs to run on x86 not on ppc. Ciao, Duncan. * If you are testing a compiler for plugin support by running it in some way, that will be a build-x-target compiler that is intended to be configured in the same way as the final host-x-target compiler. Such a build-x-target compiler will be used to build target libraries in a Canadian cross build of GCC. So always think carefully about which compiler you wish to test - and what the relevant properties of that compiler are.
Re: packaging GCC plugins using gengtype (e.g. MELT)?
On 14/03/10 21:48, Matthias Klose wrote: On 14.03.2010 13:15, Basile Starynkevitch wrote: Basile Starynkevitch wrote in http://lists.debian.org/debian-gcc/2010/03/msg00047.html Now, one of the issues about MELT & Debian packaging is the fact that melt-runtime.c (the source of melt.so plugin) uses GTY http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information & register GGC roots thru PLUGIN_REGISTER_GGC_ROOTS ... Hence, it needs gengtype (from GCC 4.5 build tree) to generate gt-melt-runtime.h [#include-ed from melt-runtime.c] so the entire GCC 4.5 source & build trees are needed to build melt.so (or any other gengtyp-ing GCC plugin). there was another request to add the gengtype binary to the package, required by the dragonegg plugin. details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562882#13 I don't think dragonegg needs this. The generated header seems to be perfectly generic, so I've simply bundled it in with the plugin source. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Basile, I tend to be quite happy with the idea of dragonegg being a good GCC plugin, since it is a good illustration of the plugin feature. I think Jack wasn't suggesting that dragonegg should be changed to not be a plugin any more. I think he was suggesting that it should live in the gcc repository rather than the LLVM repository. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Steven, I think Jack wasn't suggesting that dragonegg should be changed to not be a plugin any more. I think he was suggesting that it should live in the gcc repository rather than the LLVM repository. So, no offense, but the suggestion here is to make this subversive (for FSF GCC) plugin part of FSF GCC? What is the benefit of this for GCC? I don't see any. I just see a plugin trying to piggy-back on the hard work of GCC front-end developers and negating the efforts of those working on the middle ends and back ends. I'm sorry you see the dragonegg project so negatively. I think it is useful for gcc (though not hugely useful), since it makes it easy to compare the gcc and LLVM optimizers and code generators, not to mention the gcc and LLVM approaches to LTO. If LLVM manages to produce better code than gcc for some testcase, then it is a convenient tool for the gcc devs to find out why, and improve gcc. If gcc is consistently better than LLVM then there's nothing to worry about! Of course, right now it is LLVM that is mostly playing catchup with gcc, so for the moment it is principally the LLVM devs that get to learn from gcc, but as LLVM improves the other direction is likely to occur more often. As for "negating the efforts of those working on the middle ends and back ends", would you complain if someone came up with a new register allocator because it negates the efforts of those who work on the old one? If LLVM is technically superior, then that's a fact and a good thing, not subversion, and hopefully will encourage the gcc devs to either improve gcc or migrate to LLVM. If GCC is technically superior, then hopefully the dragonegg project will help people see this, by making it easier to compare the two technologies, and result in them giving up on LLVM and working on or using gcc instead. In my opinion a bit of friendly competition from LLVM is on the whole a good thing for gcc. That said, maybe your worry is that dragonegg makes it easier to undermine the GPL, or perhaps you don't like LLVM's BSD style license? I really have no understanding of the legal issues involved with "undermining the GPL", but I know that some of the gcc devs have thought hard about this so perhaps they can comment. I'm personally not at all interested in undermining the GPL. As for licenses, the dragonegg plugin, as a combined work of GPLv3 code (gcc), GPLv2 or later (the plugin) and GPL compatible code (LLVM), is as far as I can see GPLv3 and as such no different to gcc itself. Finally, I don't see much point in dragonegg being moved to the gcc repository. It wasn't I who suggested it. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Eric, As for "negating the efforts of those working on the middle ends and back ends", would you complain if someone came up with a new register allocator because it negates the efforts of those who work on the old one? If LLVM is technically superior, then that's a fact and a good thing, not subversion, and hopefully will encourage the gcc devs to either improve gcc or migrate to LLVM. Well, the last point is very likely precisely what Steven is talking about. GCC doesn't have to shoot itself in the foot by encouraging its developers to migrate to LLVM. I hope it was clear from my email that by "gcc" I was talking about the gcc optimizers and code generators and not the gcc frontends. If the dragonegg project shows that feeding the output of the gcc frontends into the LLVM optimizers and code generators results in better code, then gcc can always change to using the LLVM optimizers and code generators, resulting in a better compiler. I don't see how this is gcc the compiler shooting itself in the foot. Of course, some gcc devs have invested a lot in the gcc middle and back ends, and moving to LLVM might be personally costly for them. Thus they might be shooting themselves in the foot by helping the LLVM project, but this should not be confused with gcc the compiler shooting itself in the foot. All this is predicated on gcc-frontends+LLVM producing better code than the current gcc-frontends+gcc-middle/backends. As I mentioned, dragonegg makes it easier, even trivial, to test this. So those who think that LLVM is all hype should be cheering on the dragonegg project, because now they have a great way to prove that gcc does a better job! Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi David, The Graphite project and the various GCC targets participate in GCC development. Helping fix GCC bugs affecting those features, supports and grows the GCC developer base. There needs to be some mutualistic relationship. I don't see members of the LLVM community arguing that they should contribute to GCC to improve performance comparisons. as I mentioned in my email, I see dragonegg as being a useful tool for comparing the gcc and LLVM optimizers and code generators. That sounds like the kind of thing you are asking for, but perhaps I misunderstood? As Steven mentioned, LLVM has been extremely effective at utilizing FSF technology while its community complains about the FSF, GCC, GCC's leadership and GCC's developer community. It is true that plenty of people disaffected with gcc can be found in the LLVM community. Dislike of gcc or its license seems a common motivation for looking into the clang compiler for example. It seems to me that this is a natural phenomenon - where else would such people go? It would be a mistake to think that the LLVM community consists principally of gcc haters though. If GCC is so helpful and useful and effective, then work on it as well and give it credit; if GCC is so bad, then why rely on it? The rhetoric is disconnected from the actions. I'm not sure what you mean. Working on an LLVM middle-end/back-end for gcc doesn't mean I despise the gcc middle-end and back-ends, it just means that I think this is an interesting project with the potential to result in a better gcc in the long term. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Grigori, Hope my question will not completely divert the topic of this discussion - just curious what do you mean by better code? Better execution time, code size, compilation time?.. this depends on each persons needs of course. The dragonegg plugin makes it easy for people to see if the LLVM optimizers and code generators are helpful for their projects. Evaluating whether replacing whole-sale the gcc middle and backends with LLVM (which I consider pretty unlikely) is an overall win is much harder, but I doubt anyone on this mailing list needs to be told that. If yes, then why not to compare different compilers by just compiling multiple programs with GCC, LLVM, Open64, ICC, etc, separately to compare those characteristics and then find missing optimizations or better combinations of optimizations to achieve the result? how do you compile a program with LLVM? It's not a compiler, it's a set of optimization and codegen libraries. You also need a front-end, which takes the users code and turns it into the LLVM intermediate representation [IR]. The dragonegg plugin takes the output of the gcc-4.5 front-ends, turns it into LLVM IR and runs the LLVM optimizers and code generators on it. In other words, it is exactly what you need in order to compile programs with LLVM. There is also llvm-gcc, which is a hacked version of gcc-4.2 that does much the same thing, and for C and C++ there is now the clang front-end to LLVM. The big advantage of dragonegg is that it isolates the effect of the LLVM optimizers and code generators by removing the effect of having a different front-end. For example, if llvm-gcc produces slower code than gcc-4.5, this might be due to front-end changes between gcc-4.2 and gcc-4.5 rather than because the gcc optimizers are doing a better job. This confounding factor goes away with the dragonegg plugin. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Robert, b) better behavior for undefined cases this is one of the problems with using LLVM with the Ada front-end. LLVM makes pretty aggressive deductions when it sees undefined behaviour, which can result in (for example) validity checks being removed exactly in the cases when they are most needed. There are various ways of solving this problem, but I didn't implement any of them yet. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Goes away is a bit strong. In practice, front ends know about their back ends and are tuned in various ways for things to work well. Likewise, back-ends are tuned for their front-ends. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Jonathan, egcs code was always license-compatible with GCC and was always assigned to the FSF The difference is quite significant. both dragonegg and LLVM are license-compatible with GCC. The dragonegg code is licensed under GPLv2 or later, while LLVM is licensed under the University of Illinois/NCSA Open Source License, which is GPL compatible according to http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses The dragonegg plugin, being a combination of these plus GCC, is therefore GPLv3. You are of course quite right that neither LLVM nor dragonegg has its copyright assigned to the FSF. Ciao, Duncan.
Re: dragonegg in FSF gcc?
Hi Steven, FWIW, this sounds great and all... but I haven't actually seen any comparisons of GCC vs. LLVM with DragonEgg. A search with Google doesn't give me any results. Can you point out some postings where people actually made a comparison between GCC and LLVM with DragonEgg? I gave some comparisons in my talk at the 2009 LLVM developers meeting. See the links at the bottom of http://dragonegg.llvm.org/ Since then I've been working on completeness and correctness, and didn't do any additional benchmarking yet. I don't know if anyone else did any benchmarking. If so they didn't inform me. Ciao, Duncan.
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Hi Manuel, PS: On the other hand, I think that modifying GCC to suit the purposes of dragonegg or LLVM is a *bad* idea. my policy has been to only propose GCC patches that are useful to GCC itself. Well, yesterday I broke this rule and posted a patch that was only of interest to dragonegg, but let's hope that this is the exception that proves the rule, as they say :) Ciao, Duncan.
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
Hi Vladimir, thank you for doing this benchmarking. 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. Sorry about that. Can you please send me preprocessed code for the spec tests that crashed the plugin (unless you are not allowed to). By the way, if you target something (eg: i386) that doesn't have SSE support then I've noticed that the plugin tends to crash on code that does vector operations. If you have assertions turned on in LLVM then you get something like: Assertion `TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"' failed. Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ada_sse_nolib' So if the compile failures are of that kind, no need to send testcases, I already have several. Best wishes, Duncan.
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
Hi Vladimir, 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). actually it does work with -flto, in an awkward way. When you use -flto it spits out LLVM IR. You need to use -S, otherwise the system assembler tries (and fails) to compile this. You need to then use llvm-as to turn this into LLVM bitcode. You can then link and optimize the bitcode either by hand (using llvm-ld) or using the gold plugin, as described in http://llvm.org/docs/GoldPlugin.html It is annoying that gcc insists on running the system assembler when passed -c. Not running the assembler isn't only good for avoiding the -S + llvm-as rigmarole mentioned above. LLVM is now capable of writing out object files directly, i.e. without having to pass via an assembler at all. It would be neat if I could have the plugin immediately write out the final object file if -c is passed. I didn't work out how to do this yet. It probably requires some gcc modifications, so maybe something can be done for gcc-4.6. For transparent LTO another possibility is to encode LLVM bitcode in the assembler in the same way as gcc does for gimple when passed -flto. I didn't investigate this yet. Ciao, Duncan.
Re: ICE: -flto and -g
$ /usr/bin/g++-4.5 -O0 -g -flto -o kfinddialog.o -c kfinddialog.ii ../../kdeui/findreplace/kfinddialog.cpp: In member function ‘RegExpAction’: ../../kdeui/findreplace/kfinddialog.cpp:445:9: internal compiler error: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in gen_type_die_with_usage, at dwarf2out.c:18962 This looks like PR42653, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42653 Ciao, Duncan.
Re: --enable-plugin as default?
Plugin support is enabled by default if it works. I can confirm this - on my linux box I don't have to explicitly specify --enable-plugin. Ciao, Duncan.
Re: Transforms on SSA form
Hi, > I am looking to transform a tree in SSA form into a representation of it in C. you can try using LLVM (which uses an IR in SSA form): it has a "C" backend that squirts out C equivalent to the IR. The resulting C is not very nice to read though. Ciao, Duncan. PS: This is a cute way of getting an Ada to C translator, or a Fortran to C translator: use the llvm-gcc Ada/Fortran front-ends to turn your program into LLVM IR, then use the C backend to turn it into C. This currently doesn't support all constructs though (eg: exception handling).
Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000
Hi, > Sorry, I missed to mention that I used an additional option -mpc64 for > 32-bit GCC4.4. It is not possible to generate SPECFP2000 expected > results by GCC4.4 without this option. LLVM does not support this > option. And this option can significantly improve the performance. So > 32-bit comparison of SPECFP2000 should be taken with a grain of salt. what does -mpc64 do exactly? The gcc docs say: `-mpc64' rounds the the significands of results of floating-point operations to 53 bits (double precision) Does this mean that a rounding operation is performed after each fp operation, or that optimizations are permitted that don't result in accurate extended double precision values as long as they are correct to 53 bits, or something else? The LLVM code generators have an option called -limit-float-precision: -limit-float-precision= - Generate low-precision inline sequences for some float libcalls I'm not sure what it does exactly, but perhaps it is similar to -mpc64? Ciao, Duncan.
Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000
Hi Richard, > -mpc64 sets the x87 floating point control register to not use the 80bit > extended precision. This causes some x87 floating point operations > to operate faster and there are no issues with the extra roundings you > get when storing an 80bit precision register to a 64bit memory location. I see, thanks for the explanation. > Does LLVM support x87 arithmetic at all or does it default to SSE > arithmetic in 32bits? I guess using SSE math for both would be a more > fair comparison? LLVM does support the x86 floating point stack, though it doesn't support all asm expressions for it (which is why llvm-gcc disables math inlines). My understanding is that no effort has been made to produce optimal code when using the x86 fp stack, and all the effort when into SSE instead. Ciao, Duncan.
Re: LLVM as a gcc plugin?
Hi, Some time ago, there was a discussion about integrating LLVM and GCC [1]. However, with plugin infrastructure in place, could LLVM be plugged into GCC as an additional optimization plugin? I plan to start working on an llvm plugin any day now. Ciao, Duncan.
Re: LLVM as a gcc plugin?
Hi Rafael, There was some talk about it on #gcc. A plugin should be able to see all the GCC IL, so it should be able to convert it to LLVM. Keeping the current llvm-gcc interface would require some hacks *) The plugin will have to call exit to keep gcc's code generation from running. this would work when doing unit-at-a-time, but not when doing function-at-a-time. Does gcc still do function-at-a-time? Another source of problem will be the early transformations that gcc does and that are normally disabled in llvm-gcc. The one that I remember right now is c++ thunk generation. Good point. Ciao, Duncan.
Re: Where does the time go?
Hi, I don't know is it big or not to have such time spend in RTL parts. But I think that this RTL part could be decreased if RTL (magically :) would have smaller footprint and contain less details. Bah, no wand... :-) I noticed while working on the dragonegg plugin that replacing gimple -> RTL with gimple -> LLVM IR significantly reduced the amount of memory used by the compiler at -O0. I didn't investigate where the memory was going, but it seems likely that RTL either contains a whole lot more information than the LLVM IR, or doesn't represent it in a very memory efficient way. Ciao, Duncan.
Re: Using C++ in GCC is OK
On 01/06/10 10:03, Paolo Bonzini wrote: On 05/31/2010 12:30 PM, 徐持恒 wrote: I think compiler can and should be host independent, like LLVM. It is. Changes to code generation depending on the host are considered to be serious bugs, and have been long before LLVM existed. Perhaps 徐持恒 meant target independent, in the sense that with LLVM the choice of target is made at run-time, and not when building LLVM [*]. Just a guess though. Ciao, Duncan. [*] It is possible to choose which targets to build when configuring LLVM. If only one is chosen then of course that's the only one that can be chosen at run-time.
Re: GCC plugin support when using Ada
Hi PeteGarbett, I see nothing in the GCC 4.5 release notes about plugin support being language specific, and yet if I using the treehydra plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra notes), I get this I use plugins with Ada all the time, with gcc-4.5, and it works fine for me. Ciao, Duncan.
Re: plugin-provided pragmas & Fortran or Ada?
Hi Basile, Assuming a plugin (e.g. MELT) add a new pragma using PLUGIN_PRAGMAS, is this pragma usable from Ada or Fortran code? I am not very familiar with Ada or Fortran. I believe Ada has some syntax for pragmas -but do Ada pragma have the same API inside GCC plugins as C or C++ pragmas?- and I am not sure about Fortran. Many Fortran dialects or implementations parse specially some kind of comments -but I don't know if these are giving pragma events to plugins. I'm pretty sure this won't work for Ada without modifying the Ada front-end. Ciao, Duncan.
Re: plugin-provided pragmas & Fortran or Ada?
Hi Basile, Assuming a plugin (e.g. MELT) add a new pragma using PLUGIN_PRAGMAS, is this pragma usable from Ada or Fortran code? I am not very familiar with Ada or Fortran. I believe Ada has some syntax for pragmas -but do Ada pragma have the same API inside GCC plugins as C or C++ pragmas?- and I am not sure about Fortran. Many Fortran dialects or implementations parse specially some kind of comments -but I don't know if these are giving pragma events to plugins. I'm pretty sure this won't work for Ada without modifying the Ada front-end. Are there any plugin hooks for Ada pragmas? Perhaps the Ada team might consider adding some, if it is simple enough. Specific pragmas have definitely their places in plugins. I'm pretty sure there are no such plugin hooks right now. Ciao, Duncan.
Dragonegg-2.8 released
A week and a day after the LLVM 2.8 release, I'm pleased to announce the availability of the corresponding dragonegg release. Get it while it's hot! http://dragonegg.llvm.org/#gettingrelease Duncan.
Re: "Ada.Exceptions.Exception_Propagation" is not a predefined library unit
Hi Luke, a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a predefined library unit it looks like you get this error when the compiler can't find a file that it thinks forms part of the Ada library (this is determined by the name, eg: a package Ada.XYZ is expected to be part of the Ada library). For example, if the compiler looks for the spec of Ada.Exceptions.Exception_Propagation (which should be called a-exexpr.ads) but can't find it then you will get this message. At least, that's my understanding from a few minutes of rummaging around in the source code. Ciao, Duncan.
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
Hi Laurent, On Wednesday 22 February 2006 12:34, Laurent GUERBY wrote: > On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote: > > > > > > type T1 is range 0 .. 127; > > > > > > -- Compiler will choose some type for T'Base, likely to be > > > > > > -128..127 > > > > > > -- but could be Integer (implementation dependant) > > > > > > subtype T is T1 range 0 .. 100; > > > > > > R : T := 100+X-X; > > > > > > -- guaranteed work as long 100+X<=T'Base'Last and > > > > > > 100-X>=T'Base'First > > > > Is the final "conversion" a checked conversion or an unchecked conversion? > > I.e. > > are we supposed to check for overflow using 'Valid on the final result? Or > > will > > the value be truncated or a runtime error raised? > > In the full language we are supposed to check the range on the > assignement and raise the predefined exception "CONSTRAINT_ERROR" if it > fails (whatever the way in the generated code). However GNAT by default > does not generate this kind of check, you need to add -gnato to the > compile flags. my understanding is that -gnato causes the compiler to insert checks that the "100+X-X" computation does not overflow the base type. The compiler always inserts a check that the result is in the range of the target type T before performing the assignment, regardless of whether -gnato is set or not. Best wishes, Duncan.
Re: Bootstrap failure on trunk: x86_64-linux-gnu
> This code only works for one-complement machines, since it assumes a > symmetric range for Int. It breaks when UI_To_Int returns Integer'First, as > it did in this case. When it does, the abs produces an erroneous result > (since checking is disabled). So it almost doesn't matter what it puts into > Num (but it actually puts in an out-of-range value there too). Is there a simple way to have the Ada runtime (+ compiler) be built with checking enabled when bootstrapping? Thanks a lot, Duncan.
Re: Ada subtypes and base types
On Tuesday 14 March 2006 03:16, Waldek Hebisch wrote: > Jeffrey A Law wrote: > > On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote: > > > > > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value > > > allowed by given type. > > As long as you're *absolutely* clear that a variable with a > > restricted range can never hold a value outside that the > > restricted range in a conforming program, then I'll back off > > the "abuse" label and merely call it pointless :-) > > > > The scheme you're using "promoting" to a base type before all > > arithmetic creates lots of useless type conversions and means > > that the optimizers can't utilize TYPE_MIN_VALUE/TYPE_MAX_VALUE > > anyway. ie, you don't gain anything over keeping that knowledge > > in the front-end. > > > > Pascal arithmetic essentially is untyped: operators take integer > arguments and are supposed to give mathematically correct result > (provided all intermediate results are representable in machine > arithmetic, overflow is treated as user error). OTOH for proper > type checking front end have to track ranges associated to > variables. So "useless" type conversions are needed due to > Pascal standard and backend constraints. > > I think that it is easy for back end to make good use of > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment > > x := y + z * w; > > where variables y, z and w have values in the interval [0,7] and > x have values in [0,1000]. Pascal converts the above to the > following C like code: > > int tmp = (int) y + (int) z * (int) w; > x = (tmp < 0 || tmp > 1000)? (Range_Check_Error (), 0) : tmp; > > I expect VRP to deduce that tmp will have values in [0..56] and > eliminate range check. This is much the same in Ada. However the Ada runtime and compiler are compiled using a special flag (-gnatp) that turns all checks off. This is not conformant with Ada semantics. If you look at what the front end is generating during a bootstrap, you therefore see it happily converting between types and base types, and completely ignoring the possibility of out-of-range values. Someone inspecting the output of the front-end during a bootstrap could well wonder why it bothers setting TYPE_MIN_VALUE/TYPE_MAX_VALUE, and what the point of all the conversions to and from base types is. The point is that usually there would be range checks all over the place as in Waldek's example, but they have been suppressed. > Also, it should be clear that in the > assigment above artithmetic can be done using any convenient > precision. > > In principle Pascal front end could deduce more precise types (ranges), > but that would create some extra type conversions and a lot > of extra types. Moreover, I assume that VRP can do better job > at tracking ranges then Pascal front end. Duncan.
Re: Ada subtypes and base types
> > I think that it is easy for back end to make good use of
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
> >
> > x := y + z * w;
> >
> > where variables y, z and w have values in the interval [0,7] and
> > x have values in [0,1000]. Pascal converts the above to the
> > following C like code:
> >
> > int tmp = (int) y + (int) z * (int) w;
> > x = (tmp < 0 || tmp > 1000)? (Range_Check_Error (), 0) : tmp;
> >
> > I expect VRP to deduce that tmp will have values in [0..56] and
> > eliminate range check. Also, it should be clear that in the
> > assigment above artithmetic can be done using any convenient
> > precision.
> VRP can certainly do this -- I added the ability to see through
> more typecasts a while back. In general, I've tried to improve
> the ability of our optimizers to eliminate or at least "see through"
> some typecasts. However, that capability is often very limited
> and the ability to see through type casts is not pervasive in
> the optimization pipeline.
Hi Jeff, on the subject of seeing through typecasts, I was playing around
with VRP and noticed that the following "if" statement is not eliminated:
int u (unsigned char c) {
int i = c;
if (i < 0 || i > 255)
return -1; /* never taken */
else
return 0;
}
Is it supposed to be?
Thanks,
Duncan.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 17:15, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char c) {
> > int i = c;
> >
> > if (i < 0 || i > 255)
> > return -1; /* never taken */
> > else
> > return 0;
> > }
> >
> > Is it supposed to be?
> Depends...
>
> The "problem" is the parameter is marked a VR_VARYING (as it
> should be).
Should it be? I was surprised to see that all ranges are initialised
to VR_VARYING in the vrp pass, since many types have natural ranges
associated with them, for example [0, 255] for the above unsigned char;
starting off with this natural range is, well, natural, and surely
simplifies a bunch of code, by making things more uniform, eg: no need
to special case unsigned values, type conversions, ...
> Unfortunately, the VR_VARYING source operand prevents
> us from extracting a range for the result of the typecast.
>
> Sigh. We've got this "interesting" problem in VRP, namely that
> we can sometimes extract ranges for operations on VR_VARYING
> objects, but generally we punt. To compensate we often create
> a range, say 0..MAXINT for an unsigned object -- that's effectively
> a VARYING range, but the rest of VRP doesn't pessimize so much
> when presented with 0..MAXINT vs VARYING.
>
> If we weren't so pessimistic with VR_VARYING or we always created
> ranges, even if they cover TYPE_MIN .. TYPE_MAX then this wouldn't
> be a problem.
>
> I'll see what I can cobble together...
That would be great.
All the best,
Duncan.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 18:01, Jeffrey A Law wrote: > On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote: > > > Should it be? I was surprised to see that all ranges are initialised > > to VR_VARYING in the vrp pass, since many types have natural ranges > > associated with them, for example [0, 255] for the above unsigned char; > > starting off with this natural range is, well, natural, and surely > > simplifies a bunch of code, by making things more uniform, eg: no need > > to special case unsigned values, type conversions, ... > Depends on who you talk to -- we certainly have a problem in that we > have two ways to represent the same thing and the optimizer treats > the two representations differently. > > In a world where we could handle VR_VARYING without pessimizing so > much, then I don't think either representation would be clearly > better than the other. Is memory use a problem here? VR_VARYING has the advantage of using a bit less memory. On the other hand, I guess you could introduce the convention that VR_RANGE with null min/max means to use TYPE_MIN/ TYPE_MAX, or something along those lines. Ciao, D.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char c) {
> > int i = c;
> >
> > if (i < 0 || i > 255)
> > return -1; /* never taken */
> > else
> > return 0;
> > }
> >
> > Is it supposed to be?
> Fixed thusly. Bootstrapped and regression tested on i686-pc-linux-gnu.
Thanks a lot - building now.
Best wishes,
Duncan.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char c) {
> > int i = c;
> >
> > if (i < 0 || i > 255)
> > return -1; /* never taken */
> > else
> > return 0;
> > }
> >
> > Is it supposed to be?
> Fixed thusly. Bootstrapped and regression tested on i686-pc-linux-gnu.
Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
of suboptimal range calculations in the Ada code I'm looking at, but these
now just coming from having everything initialised to VR_VARYING rather than
[TYPE_MIN, TYPE_MAX]. Do you know of any way of getting variables with
non-trivial TYPE_MIN/TYPE_MAX values in C? I ask because I'd rather produce
test cases in C than Ada, since everyone has access to a C compiler :)
All the best,
Duncan.
Re: Ada subtypes and base types
On Thursday 23 March 2006 11:31, Eric Botcazou wrote: > > Hi Jeff, this seems to work nicely - thanks again. > > Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64. Which ones? Ciao, Duncan.
Re: Ada subtypes and base types
On Thursday 23 March 2006 17:14, Andrew Pinski wrote: > > On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote: > > > > > > Well - we could hack a new type attribute to specify min/max values... > > Or maybe try to using C++ instead since C++ rules for enums are > different > than C :). Well, I like the attribute idea since it gives much more flexibility in making examples. Also, though I guess this only matters to me, in order to produce C++ examples I'd have to build the compiler with C++ support, which I'd rather not do since I have no use for C++ otherwise. Ciao, Duncan.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char c) {
> > int i = c;
> >
> > if (i < 0 || i > 255)
> > return -1; /* never taken */
> > else
> > return 0;
> > }
> >
> > Is it supposed to be?
> Fixed thusly. Bootstrapped and regression tested on i686-pc-linux-gnu.
Hi Jeff, while your patch catches many cases, the logic seems a bit wonky
for types with TYPE_MIN/TYPE_MAX different to those that can be deduced
from TYPE_PRECISION. For example, there is nothing stopping inner_type
having a bigger TYPE_PRECISION than outer_type, but a smaller
[TYPE_MIN,TYPE_MAX] range. For example, outer_type could be a byte with
range 0 .. 255, and inner_type could be an integer with range 10 .. 20.
I think this logic:
! if (vr0.type == VR_RANGE
! || (vr0.type == VR_VARYING
! && TYPE_PRECISION (outer_type) > TYPE_PRECISION (inner_type)))
! {
! tree new_min, new_max, orig_min, orig_max;
should really test whether
TYPE_MAX (inner_type) < TYPE_MAX (outer_type) || TYPE_MIN (inner_type)
> TYPE_MIN (outer_type)
and take the appropriate action if so.
By the way, I hacked tree-vrp to start all value ranges for INTEGRAL_TYPE_P
variables to [TYPE_MIN, TYPE_MAX]. It certainly helps with eliminating many
Ada range checks. Maybe the compiler will even bootstrap :)
This approach has advantages, even if TYPE_MIN/MAX are those given by
TYPE_PRECISION. For example, after incrementing a variable you automatically
get the range [TYPE_MIN+1,INF]. The approach also has disadvantages: for
example, the notion of an "interesting" range has to be adjusted, since now
VR_RANGE can be pretty uninteresting; and how interesting is [TYPE_MIN+1,INF]
in practice? Also, there's likely to be extra overhead, due to pointless
computations and comparisons on [TYPE_MIN, TYPE_MAX] ranges, especially if
they are symbolic. Furthermore, in the case of symbolic TYPE_MIN and/or
TYPE_MAX,
it may be possible to deduce better ranges using the max/min range given by
TYPE_PRECISION, since these are compile time constants, rather than using
[TYPE_MIN,TYPE_MAX].
As I final thought, it struck me that it might make sense to associate the
range [TYPE_MIN, TYPE_MAX] to the type (rather than to variables of the type),
and extend the notion of equivalence so that a variable's range can be
equivalent to the range of it's type. This is probably nonsensical, but
I can't tell given my current minuscule understanding of VRP ;)
All the best,
Duncan.
Re: Ada subtypes and base types
Hi Jeff,
> > By the way, I hacked tree-vrp to start all value ranges for INTEGRAL_TYPE_P
> > variables to [TYPE_MIN, TYPE_MAX]. It certainly helps with eliminating many
> > Ada range checks. Maybe the compiler will even bootstrap :)
> The thing to check will be compile-time performance -- in general
> with propagators such as VRP, CCP and CPROP it's compile-time
> advantageous to drop to a VARYING state in the lattice as quickly
> as possible. The flipside is you can sometimes miss transformations
> when there's cases when you can use a VARYING object in an expression
> and get a useful value/range.
>
> Basically the two extremes we need to look at are:
>
> 1. Give everything a range, even if it's just TYPE_MIN/TYPE_MAX. In
> this case VR_VARYING disappears completely as it's meaningless.
>
> 2. Anytime we're going to record a range TYPE_MIN/TYPE_MAX, drop to
> VARYING. The trick then becomes to find all those cases where we
> have an expression involving a VARYING which produces a useful
> range (such as widening typecasts, IOR with nonzero, etc etc).
I've thought of a different approach: add ASSERT_EXPRs on those subroutine
parameters, function return values and (perhaps) global variables which have
exotic TYPE_MIN/TYPE_MAX values ("exotic" means different from what you'd
expect given the signedness and TYPE_PRECISION). The assertion is that the
variable is in the range [TYPE_MIN,TYPE_MAX]. Except for this, VRP would
completely ignore exotic TYPE_MIN/TYPE_MAX values. In particular, nothing
special would be done for local variables of a type with an exotic range.
For example, consider
int v (restricted_int i) {
restricted_int j;
if (j > 100) return -1;
j = i;
if (j > 100) return -1;
return 0;
}
where restricted_int has TYPE_MAX=100 (this type does not exist in C of course).
Then a single ASSERT_EXPR would be added, something like this (I know the syntax
is wrong, this is just to convey the idea):
int v (restricted_int i) {
ASSERT_EXPR (i < 100);
restricted_int j;
if (j > 100) return -1;
j = i;
if (j > 100) return -1;
return 0;
}
Thus the second "if" statement would be eliminated but not the first.
As mentioned, except for inserting the ASSERT_EXPR, VRP can ignore
the fact that the type has an exotic TYPE_MAX, and reason as if TYPE_MAX
was that given by TYPE_PRECISION, as for a standard C int. The
exoticness is all captured in the ASSERT_EXPR.
I think this scheme is enough to get good optimisation for a language like
Ada. Advantages of this approach:
(A) No overhead for languages like C which lack exotic type ranges.
(B) Simplifies VRP, since (except for inserting the ASSERT_EXPRs) it
can completely ignore the existence of exotic ranges; and people working
on it won't need to think about them either. From a maintenance point
of view this is excellent: as second class citizens, types with exotic
ranges are sure to be forgotten about 99% of the time when someone modifies
VRP; with this scheme, being forgotten about doesn't matter.
(C) Avoids over-aggressive optimisation on uninitialised variables. Consider
the variable j in the example above. If VRP considered it to be in the range
[-INF,100] because it is of type restricted_int, then it would eliminate the
first "if" statement. This kind of thing is extremely dangerous. Probably
the programmer placed the "if" statement there to check that the variable
really was in it's range. Eliminating it would be legal in Ada, indeed the
program is wrong, however in practice this kind of thing is unwise: it doesn't
gain you much from an optimisation point of view, but it can make programs
behave in very unexpected ways. It may be unwise to add ASSERT_EXPRs for
global variables with exotic ranges, since they could be uninitialised.
Furthermore, this scheme agrees well with Ada semantics. What does
it mean to say that a subroutine parameter is of type restricted_int? It
really means that (1) it is of type int; and (2) it's value has been checked,
before the subroutine call, and is guaranteed to be <= 100. The code to do
the checking is automatically inserted by the compiler, which adds some code
like this at the point of the subroutine call:
if x > 100
raise_some_exception;
else
result = v (x);
Running VRP on this would cause an ASSERT_EXPR to be placed before the call:
if x > 100
raise_some_exception;
else {
ASSERT_EXPR (x <= 100);
result = v (x);
}
I'm basically suggesting that this same ASSERT_EXPR be duplicated inside the
subroutine v. This is OK, because the compiler guarantees that any parameter
passed to v always satisfies this assertion, for every call to v.
The compiler also guarantees that the result of a function call is in the range
of the return type (by inserting a check at the end of the function, if
necessary).
Thus an ASSERT_EXPR can be placed on the result of a f
Re: Ada subtypes and base types
Hi Jeff, On Monday 27 March 2006 21:00, Jeffrey A Law wrote: > On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote: > > > Start by looking at tree-vrp.c:infer_value_range. > I'm not so sure this is the best place to start. it seems a good place for adding ASSERT_EXPRs on function return values though. > It seems to me that the asserts could be registered at the > start of insert_range_assertions. > > Just walk the parameter list and extract the default definition > for each parameter and register an appropriate assertion based > on the parameter's type. I agree, however I don't yet know how to walk the parameter list, so any hints would be welcome :) > Note that this basically avoids reaching any kind of conclusion > about the best way to handle our representational issue with > VR_VARYING vs just creating a range from TYPE_MIN_VALUE to > TYPE_MAX_VALUE. There's a part of me which would recommend > reaching some conclusions on that issue before going down the > path of special casing parameters. I agree that this kind of special casing by the middle-end is all wrong - the front-end should do it. Personally I think the Ada frontend should never pass types with a restricted range to the middle-end (in Ada terms, this means that the middle-end would only ever see base types). If the front-end knows (or is prepared to have the optimisers assume) that the value of a variable is in some restricted range, then the front-end should itself insert an appropriate ASSERT_EXPR in the tree that it is going to pass to the middle-end. Of course this means reworking the middle-end a bit so it can handle assertions right from the beginning. Not to mention reworking the Ada front-end. But it gives more control to the front-end, and it would likely be an overall code simplification for the middle-end, and surely a conceptual simplification, since no-one would have to worry about funny ranges any more, and ASSERT_EXPRs are easy to understand. After all, saying that a variable belongs to a type T with a restricted range means: (A) it belongs to the base type (int, for example), and (B) the value that it holds is within some subrange. (B) is essentially an assertion, exactly of the kind ASSERT_EXPR was introduced to capture. The problem with using types like T is that sometimes (B) holds, sometimes it doesn't. A variable declared to be of type T won't usually satisfy (B) until it gets an initial value. If the uninitialised variable is passed to a procedure, now you have a procedure parameter of type T which doesn't satisfy (B). So when are the optimisers allowed to assume (B)? The Ada standard carefully defines the possible outcomes of using an out-of-range variable; the middle-end could try to implement these subtle semantics. But surely it shouldn't even try: it should leave Ada semantics to the Ada front-end, and provide a means by which the front-end can tell it what it may assume. ASSERT_EXPRs seem like a decent way of doing this, in any case a better way than the current type based system. That said, I'm still planning to implement the ASSERT_EXPR on subroutine parameters scheme, to check that it really is feasible, and to learn about the middle-end. > Note that this basically avoids reaching any kind of conclusion > about the best way to handle our representational issue with > VR_VARYING vs just creating a range from TYPE_MIN_VALUE to > TYPE_MAX_VALUE. There's a part of me which would recommend > reaching some conclusions on that issue before going down the > path of special casing parameters. If exotic TYPE_MIN, TYPE_MAX values did not exist, would you be still feel there was an issue here? Also, I now think it would be a mistake to initialise all variable ranges to [TYPE_MIN, TYPE_MAX]. I implemented this, and got great optimisation - a bit too much optimisation in fact! For example, you can't test whether a variable is in range using the obvious "if" statement anymore, since VRP will eliminate it (after all, it "knows" the variable is in range already, because it was told so). Do the Ada people want this level of optimisation? I'm pretty sure they don't: I've heard Robert Dewar say that he considers exactly this optimisation (eliminating an "if" on an uninitialised variable based on the range given in the type definition) to be a bad idea. So that means that initialising variables to [TYPE_MIN,TYPE_MAX] is likely not acceptable in general. Actually, it might be acceptable if the Ada front-end was modified to only declare a variable to be of a type with a restricted range when it is sure (or is willing to have the optimisers assume) that the value is in that range. For example, uninitialised variables would have to be declared to be of the base type (no funny range), and would be cast to the restricted range type when the value is known to be in range, perhaps because Ada semantics ensure it is in range, or because a range check was just performed. [In the scheme I suggested in my
Re: Ada subtypes and base types
Hi Jeff, thanks for the info. > > I agree that this kind of special casing by the middle-end is all > > wrong - the front-end should do it. > I'd disagree. While it may at first seem useful to have ASSERT_EXPRs > live through the entire optimization pipeline, they're actually going > to get in the way of a fair amount of simple optimizations, specifically > copy propagation and the secondary optimizations exposed by > copy propagation. > > > > > > > > Personally I think the Ada frontend should never pass types with > > a restricted range to the middle-end (in Ada terms, this means > > that the middle-end would only ever see base types). > I certainly do agree with this -- I've been pretty vocal about > that already :-) That still leaves the problem of how the Ada front-end tells the middle-end that a variable is known to be in a certain range. Due to the way the language works, the front-end often does know a useful range, helpful for optimisation. If using types with strange ranges is out, and ASSERT_EXPRs aren't appropriate, what is left? After further thought, I'm not so against the use of these ranges as I was... > > So that means that initialising variables to [TYPE_MIN,TYPE_MAX] > > is likely not acceptable in general. > No, the problems referenced above are latent bugs that need to > be fixed. They do not argue that initializing to [TYPE_MIN, TYPE_MAX] > is the wrong direction. You are right. > What needs to drive the representational solution is the ability to > get the optimizations we want without paying a hefty compile-time > or maintenance penalty. I'm playing with the code right now, getting rid of VR_VARYING. Do you have any suggestions for benchmarking it? Ciao, Duncan.
Re: Ada subtypes and base types
On Wednesday 29 March 2006 23:28, Tom Tromey wrote: > >>>>> "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes: > > Duncan> That still leaves the problem of how the Ada front-end tells the > Duncan> middle-end that a variable is known to be in a certain range. Due > Duncan> to the way the language works, the front-end often does know a useful > Duncan> range, helpful for optimisation. If using types with strange ranges > Duncan> is out, and ASSERT_EXPRs aren't appropriate, what is left? > > Yeah, there's got to be something. > > On irc today we were discussing handling 'this' in gcj. We can add an > attribute to the argument to mark it as non-null... but strangely > there doesn't seem to be a way to mark other local variables as > known-non-null -- a curious deficiency. If the front-end was allowed to place ASSERT_EXPRs in the trees it passes to the middle-end, then you could place such assertions on the appropriate local variables and voila. Jeff claimed that this would cause serious problems for the copy propagation pass, but I don't see why. All the best, Duncan.
Re: Ada subtypes and base types
> > On irc today we were discussing handling 'this' in gcj. We can add an > > attribute to the argument to mark it as non-null... but strangely > > there doesn't seem to be a way to mark other local variables as > > known-non-null -- a curious deficiency. > It seems to me that for other locals that the non-null property > ought to be a property of how those locals are assigned a value. > ie, if we're going to be able to derive a non-null for a local we > should be able to derive it from the RHS of the assignment(s) to > that local. > > IIRC "this" is actually a parameter and thus there's no assignment > we can derive information from. Ada has a notion of "non-null pointer type". A variable declared to be of such a type is required to have a non-null initial value, so VRP can presumably work out that it is non-null from the initialization. The main interest of such a type is in declaring subroutine parameters and function return values, in which case the existing attribute is likely good enough. So the Ada way of handling these types maps pretty well to what you said. Ciao, Duncan.
New Ada testcases
I've started adding a bunch of regression tests to the
Ada dejagnu testsuite (see below for the current state).
I've accumulated these over several years, and almost all
of them have been reported in gcc bugzilla (not many of
these) or to ACT (the funny package names are ACT tracking
numbers).
However it's not clear to me how to add multi-package tests.
Some of my test cases consist of more than a_package.ads,
a_package.adb (think of tests involving interaction of child
packages with parent packages for example - they necessarily
involve several compilation units). Logically speaking, the
test only needs to be run on the main package, the subsidiary
packages don't need to be tested individually. However the
testsuite infrastructure tests all bodies. How to tell it
to ignore some? Likewise for tests in gnat.dg/specs.
Thanks for your help,
Duncan.
Index: testsuite/gnat.dg/f202_014.adb
===
--- testsuite/gnat.dg/f202_014.adb (revision 0)
+++ testsuite/gnat.dg/f202_014.adb (revision 0)
@@ -0,0 +1,12 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+-- { dg-options "-gnat05" }
+
+package body F202_014 is
+ procedure R (X : access constant Integer) is
+ B : Boolean;
+ begin
+ B := X = I;
+ end;
+end;
Index: testsuite/gnat.dg/ec13_012.ads
===
--- testsuite/gnat.dg/ec13_012.ads (revision 0)
+++ testsuite/gnat.dg/ec13_012.ads (revision 0)
@@ -0,0 +1,2 @@
+function EC13_012 return Boolean;
+pragma Pure_Function (EC13_012);
Index: testsuite/gnat.dg/eb24_002.ads
===
--- testsuite/gnat.dg/eb24_002.ads (revision 0)
+++ testsuite/gnat.dg/eb24_002.ads (revision 0)
@@ -0,0 +1,2 @@
+procedure EB24_002;
+pragma Pure (EB24_002);
Index: testsuite/gnat.dg/e224_009.adb
===
--- testsuite/gnat.dg/e224_009.adb (revision 0)
+++ testsuite/gnat.dg/e224_009.adb (revision 0)
@@ -0,0 +1,16 @@
+-- Wrong warning.
+
+-- { dg-do compile }
+-- { dg-options "-gnatwa" }
+
+procedure E224_009 is
+ type R is record
+ I : Integer;
+ end record;
+ An_R : aliased R;
+ type R_P is access all R;
+ A : array (1 .. 1) of R_P;
+begin
+ A (1) := An_R'Access;
+ A (1).I := 2;
+end;
Index: testsuite/gnat.dg/f109_018.adb
===
--- testsuite/gnat.dg/f109_018.adb (revision 0)
+++ testsuite/gnat.dg/f109_018.adb (revision 0)
@@ -0,0 +1,13 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+
+procedure F109_018 is
+ procedure Q (I : Integer) is
+ begin null; end;
+ procedure Q2 (I : Integer) renames Q;
+begin
+ if Q2'Mechanism_Code (1) = 1 then
+ null;
+ end if;
+end;
Index: testsuite/gnat.dg/eb30_003.adb
===
--- testsuite/gnat.dg/eb30_003.adb (revision 0)
+++ testsuite/gnat.dg/eb30_003.adb (revision 0)
@@ -0,0 +1,12 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+-- { dg-options "-gnat05" }
+
+package body EB30_003 is
+ procedure F (A : A_Type) is
+ An_A : access A_Type;
+ begin
+ An_A := A.An_A;
+ end;
+end;
Index: testsuite/gnat.dg/eb14_003.adb
===
--- testsuite/gnat.dg/eb14_003.adb (revision 0)
+++ testsuite/gnat.dg/eb14_003.adb (revision 0)
@@ -0,0 +1,14 @@
+-- Program_Error, due to <> not default initializing the array elements.
+
+-- { dg-do run }
+-- { dg-options "-gnat05" }
+
+with Ada.Containers.Doubly_Linked_Lists;
+procedure EB14_003 is
+ package Lists is new Ada.Containers.Doubly_Linked_Lists (Boolean);
+ type Array_Type is array (Boolean) of Lists.List;
+ type Record_Type is record An_Array : Array_Type; end record;
+ A_Record : Record_Type := (An_Array => <>);
+begin
+ Lists.Append (A_Record.An_Array (True), True);
+end;
Index: testsuite/gnat.dg/f202_014.ads
===
--- testsuite/gnat.dg/f202_014.ads (revision 0)
+++ testsuite/gnat.dg/f202_014.ads (revision 0)
@@ -0,0 +1,5 @@
+package F202_014 is
+ type IA is access all Integer;
+ I : IA;
+ procedure R (X : access constant Integer);
+end;
Index: testsuite/gnat.dg/eb30_003.ads
===
--- testsuite/gnat.dg/eb30_003.ads (revision 0)
+++ testsuite/gnat.dg/eb30_003.ads (revision 0)
@@ -0,0 +1,6 @@
+package EB30_003 is
+ type A_Type is private;
+ procedure F (A : A_Type);
+private
+ type A_Type is record An_A : access A_Type; end record;
+end;
Index: testsuite/gnat.dg/e701_012.adb
===
--- testsuite/gnat.dg/e701_012.adb (revision 0)
+++ testsuite/gnat.dg/e701_012.adb (revision 0)
@@ -0,0 +1,11 @@
+--
Re: Fixed-Point Arithmetic Project
> We are working on a project to add fixed-point arithmetic support to GCC. > A GCC project description page is available here > http://gcc.gnu.org/wiki/FixedPointArithmetic > and we will create a GCC branch in the near future. If you have > any suggestions or comments, please respond. I expect the Ada front-end people will be interested: the Ada language incorporates binary and decimal fixed point types. AFAIK, it is all done using emulation at the moment. Best wishes, Duncan.
Re: Fixed-Point Arithmetic Project
On Friday 22 September 2006 09:38, Arnaud Charlet wrote: > > > We are working on a project to add fixed-point arithmetic support to GCC. > > > A GCC project description page is available here > > > http://gcc.gnu.org/wiki/FixedPointArithmetic > > > and we will create a GCC branch in the near future. If you have > > > any suggestions or comments, please respond. > > > > I expect the Ada front-end people will be interested: the Ada language > > incorporates binary and decimal fixed point types. AFAIK, it is all > > done using emulation at the moment. > > Not sure what you mean by "emulation". The implementation provided in > GNAT is indeed a full implementation of Ada fixed point semantics. I mean that no use is made of special hardware support. This is in analogy to "floating point emulation", for processors with no fp support. > It can probably be used either as a reference implementation, or as a base for > comparison (e.g. correctness comparison). Best wishes, Duncan.
Re: Explicit field layout
> I am writing a new GCC front end. One of the features provided by my > language (CIL) is explicit field layout and size for records. > > I don't know if any other languaje supported by GCC provides this > feature. If that's the case, please point me to it so that I can see how > to do it. Ada provides this. See for example section 13.5 of the reference manual (http://www.adaic.com/standards/index.html). Best wishes, Duncan.
Re: Fixed-Point Arithmetic Project
On Saturday 23 September 2006 17:08, Robert Dewar wrote: > Duncan Sands wrote: > >> We are working on a project to add fixed-point arithmetic support to GCC. > >> A GCC project description page is available here > >> http://gcc.gnu.org/wiki/FixedPointArithmetic > >> and we will create a GCC branch in the near future. If you have > >> any suggestions or comments, please respond. > > > > I expect the Ada front-end people will be interested: the Ada language > > incorporates binary and decimal fixed point types. AFAIK, it is all > > done using emulation at the moment. > > I don't know what emulation means here, obviously there is little > hardware support. Ada generates perfectly efficient fixed-point code, > but the code is generated in the front end. It might be possible > to share back end code if the semantics is exactly what Ada needs. Making sure the semantics matches what Ada needs is a good reason to get involved at this early stage. Ciao, Duncan.
Re: clang and FSF's strategy
Hi David, > At any rate, if you want to bash the strategies of the GNU project, these lists are the wrong place to go. Try doing it on the Clang list though I am skeptical that they do not have better things to do as well. the Clang list is for technical rather than political discussion, as you guessed. I unfortunately don't have any helpful suggestions for where Michael could best continue this discussion, but I'm pretty sure it's not the clang mailing list. Best wishes, Duncan.
Re: clang and FSF's strategy
On 23/01/14 12:42, Michael Witten wrote: On Thu, Jan 23, 2014 at 11:04 AM, Duncan Sands wrote: the... list is for technical rather than political discussion That's just it; that's the whole point. The *political* aspects are dictating the *technical* aspects. Not for clang they aren't, so please leave the clang mailing list out of it. Best wishes, Duncan. So... like it or not, that makes this list exactly the right place to have this discussion.
Re: clang vs free software
Hi Vladimir, o Comparing LLVM and GCC on Fortran benchmarks. LLVM has no fortran FE and just quietly call system GCC. So comparison of LLVM and GCC on Fortran benchmarks means comparison of system GCC and a given GCC. a few people are working on LLVM based Fortran compilers. I'm not sure how far they got though. I think the one farthest along is this one: https://github.com/hfinkel/lfort/ There is also: https://github.com/isanbard/flang/ Of course you can always cheat and use the GCC Fortran front-end, using the dragonegg plugin bridging it to LLVM, but as I'm not maintaining dragonegg any more (no time) this solution is likely to bitrot fast unless someone else picks up the project. Best wishes, Duncan.
Re: GCC 4.7.0RC: Mangled names in cc1
Hi, I believe this is not intentional, right? No, this is intentional. We bootstrap the compiler using the C++ front-end now. We build stage1 with the C compiler and then build stages 2 and 3 with the C++ compiler. OK. However, this means that plug-ins must now be built with g++, except when GCC was configured with --disable-build-poststage1-with-cxx. This seems difficult to deal with, for plug-in writers. I’m really concerned about the maintenance difficulties that this change entails for external plug-ins. does this mean that if built with --disable-bootstrap then symbols aren't mangled, while otherwise they are? I personally don't mind if symbols are mangled or not, but it would be simpler if symbols can be relied upon to always be mangled, or always not be mangled... I guess I could work around it by detecting at build time whether the targeted gcc has mangled symbols, and using extern "C" only if not mangled. It would help if there was a simple way to ask gcc if it is using mangled symbols or not. Ciao, Duncan.
Re: Switching to C++ by default in 4.8
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
Given the above assumption, now I doubt the necessity of accessor
macros or C++ getter/setter method.
Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
"tree->get_code()" ?
On a side note, the dragonegg plugin (which is written in C++) defines
/// isa - Return true if the given tree has the specified code.
template bool isa(const_tree t) {
return TREE_CODE(t) == code;
}
which lets you write things like
if (isa(t)) ...
and so on.
While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE",
the main advantage to my mind is that it is a standard C++ idiom that should
be natural for many C++ programmers.
Ciao, Duncan.
Re: SPEC2000 comparison of LLVM-3.2 and coming GCC4.8 on x86/x86-64
Hi Vladimir, thanks for these numbers. ... Therefore I had to use *Dragonegg* (a GCC plugin which uses LLVM backend instead of GCC backend) for generation of Fortran benchmarks by LLVM. ... I believe such progress is achieved mostly because of a *new RA* introduced in LLVM 3.0 and *auto-vectorization*. I don't think it can be auto-vectorization, because I forgot to turn on the LLVM auto-vectorizer in dragonegg-3.2 (oops!). Ciao, Duncan.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
Hi, > I'm using the ppc-linux gcc-4.2.2 compiler and noted the code > size have increased significantly (about 40%!), comparing with > old 4.0.0 when using the -Os option. Same code, same compile- > and configuration-time options. Binutils are differ > (2.16.1 vs 2.17.50), though. what LLVM version is old 4.0.0? Are you compiling C++ (I don't know what CSiBE is)? Are you using exception handling? > I've looked at the CSiBE testing results for ppc-elf with -Os, > comparing gcc_4_0_0 with mainline and found that the mainline > actually optimizes better, at least for the CSiBE test environment. > After some analysis I've came to the following results: > Number of packages in the CSiBE test environment: 863 > N of packages where mainline GCC optimizes better: 290 > N of packages where mainline GCC optimizes worse: 436 From these numbers it looks like llvm-gcc is better than mainline most of the time. However you say: "... found that the mainline actually optimizes better". Can you please clarify. Best wishes, Duncan.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
> LLVM? From what I know llvm-gcc is an alternative for gcc. Are any > parts of LLVM used in current GCC? None of what I know. Sorry, I confused my mailing lists and thought you had asked on the LLVM mailing list. This explains why I didn't understand your questions :) Sorry about the noise, Duncan.
Re: ACATS Results for powerpc-rtems on Trunk
Hi, > 4.2.3 only failed c380004, c761007, and c953002. c380004 can be considered to be an expected failure. It also fails on x86-linux, and this is normal because the code produced by the front-end (gcc-4.2) can't possibly pass. Best wishes, Duncan.
Re: LLVM 2.2
> One of the big changes is that we now recommend the GCC 4.2-based > front-end, Another is that it supports Ada (32 bit x86 on linux only for the moment) and Fortran to some extent. I'm currently adding build instructions for these two languages to http://llvm.org/docs/CFEBuildInstrs.html (should be up in a day or two). The release notes detail what works and what doesn't. Ciao, Duncan.
Re: LLVM 2.2
> Another is that it supports Ada (32 bit x86 on linux only for the moment) > and Fortran to some extent. I'm currently adding build instructions for > these two languages to http://llvm.org/docs/CFEBuildInstrs.html (should > be up in a day or two). The release notes detail what works and what > doesn't. I've added build instructions for the Ada f-e. They can be found at http://llvm.org/docs/GCCFEBuildInstrs.html Duncan.
Re: LLVM 2.3 Released
>Are there any specific plans for moving llvm-gcc from the > gcc 4.2 to the gcc 4.3 code base? I plan to port llvm-gcc to gcc head, since I'm interested in the Ada front-end and the Ada support in gcc-4.4 is much better than in gcc-4.2. However I can't say when this will happen, since I don't have much time to spend on it. Best wishes, Duncan.
Warnings when building the Ada f-e
Building gcc from svn today I see the following: prj-nmsc.adb: In function ‘Prj.Nmsc.Check_Naming_Schemes’: prj-nmsc.adb:3272: warning: ‘Casing’ may be used uninitialized in this function ... g-socket.adb: In function ‘GNAT.SOCKETS.SEND_SOCKET’: g-socket.adb:1786: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.RECEIVE_SOCKET’: g-socket.adb:1586: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.GET_SOCKET_NAME’: g-socket.adb:1001: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.CONNECT_SOCKET’: g-socket.adb:623: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.CONNECT_SOCKET’: g-socket.adb:655: warning: ‘REQ’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.BIND_SOCKET’: g-socket.adb:396: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.ACCEPT_SOCKET’: g-socket.adb:277: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.GET_PEER_NAME’: g-socket.adb:929: warning: ‘SIN’ is used uninitialized in this function ... a-strmap.adb: In function ‘Ada.Strings.Maps.To_Set’: a-strmap.adb:269: warning: ‘Result’ is used uninitialized in this function a-strmap.adb: In function ‘Ada.Strings.Maps.To_Set’: a-strmap.adb:285: warning: ‘Result’ is used uninitialized in this function ... g-comlin.adb: In function ‘GNAT.COMMAND_LINE.FIND_LONGEST_MATCHING_SWITCH’: g-comlin.adb:96: warning: ‘PARAM’ may be used uninitialized in this function g-comlin.adb:96: note: ‘PARAM’ was declared here This is x86_64-unknown-linux-gnu. Ciao, Duncan.
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
> > However if GPLv3 is such a huge issue > > at Apple, it does make one wonder if llvm will ever see a gcc front-end > > newer > > than the current 4.2 one. > > The LLVM folks are writing a new frontend anyhow. In the future they > presumably plan to stop using the gcc frontend. gcc's code is so > tangled anyhow, it's not like using the gcc frontend somehow makes > LLVM compile code the same way gcc does. I'm quite interested in porting llvm-gcc to gcc head, in order to get better Ada support. Apple isn't planning Ada support in their new compiler (clang) as far as I know :) Duncan. PS: I have no connection with Apple.
Re: Optimization of conditional access to globals: thread-unsafe?
Hi Tomash, > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O0 mmap.c -o mmap > moonlight:/tmp$ ./mmap > GCC is the best compiler ever! > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O1 mmap.c -o mmap > moonlight:/tmp$ ./mmap > Segmentation fault I don't see this with gcc 4.1 or 4.2. Just a data point. Ciao, Duncan.
