RE: Release novops attribute for external use?
Something like printf (Though I read somewhere glibc extension of printf make it non-pure). Bingfeng > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Andrew Haley > Sent: 12 April 2010 17:34 > To: gcc@gcc.gnu.org > Subject: Re: Release novops attribute for external use? > > On 04/12/2010 05:27 PM, Bingfeng Mei wrote: > > Hello, > > One of our engineers requested a feature so that > > compiler can avoid to re-load variables after a function > > call if it is known not to write to memory. It should > > slash considerable code size in our applications. I found > > the existing "pure" and "const" cannot meet his requirements > > because the function is optimized out if it doesn't return > > a value. > > If a function doesn't write to memory and it doesn't return a > value, what is the point of calling it? > > Andrew. > >
Re: Release novops attribute for external use?
On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei wrote:
> Something like printf (Though I read somewhere glibc extension of printf
> make it non-pure).
Surely printf writes to global memory (it clobbers the stdout FILE*)
As for the original question - novops is internal only because its
semantics is purely internal and changes with internal aliasing
changes.
Now, we still lack a compelling example to see what exact semantics
you are requesting? I suppose it might be close to a pure but
volatile function? Which you could simulate by
dummy = pure_fn ();
asm ("" : "g" (dummy));
or even
volatile int dummy = pure_fn ();
Richard.
> Bingfeng
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> Behalf Of Andrew Haley
>> Sent: 12 April 2010 17:34
>> To: gcc@gcc.gnu.org
>> Subject: Re: Release novops attribute for external use?
>>
>> On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
>> > Hello,
>> > One of our engineers requested a feature so that
>> > compiler can avoid to re-load variables after a function
>> > call if it is known not to write to memory. It should
>> > slash considerable code size in our applications. I found
>> > the existing "pure" and "const" cannot meet his requirements
>> > because the function is optimized out if it doesn't return
>> > a value.
>>
>> If a function doesn't write to memory and it doesn't return a
>> value, what is the point of calling it?
>>
>> Andrew.
>>
>>
>
Re: Release novops attribute for external use?
On 04/13/2010 10:45 AM, Richard Guenther wrote: > On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei wrote: >> Something like printf (Though I read somewhere glibc extension of printf >> make it non-pure). > > Surely printf writes to global memory (it clobbers the stdout FILE*) I suppose a system call to something such as sync(2) is something with a side-effect that does not touch memory, or at least the memory of the process calling it. But you still don't want to reorder calls to such functions, even though they don't clobber memory. I think the semantics of this are going to be extremely hard to define unambiguously. Andrew.
RE: Release novops attribute for external use?
>
> Surely printf writes to global memory (it clobbers the stdout FILE*)
>
OK, the point is not about whether printf is pure or not. Instead, if
programmer knows the callee function such as printf contains no
memory access that affects operations inside caller function, and he
would like to have a way to optimize the code. Our engineer gave following
example:
void myfunc(MyStruct *myStruct)
{
int a,b;
a = myStruct->a;
printf("a=%d\n",a);
b = 2*mystruct->a; // I would like to have the compiler acting as if
I had written b = 2*a;
...
}
Providing such attribute may be potentially dangerous. But it is just
like "restrict" qualifier and some other attributes, putting responsibilty
of correctness on the programmer. "novops" seems to achieve that effect,
though its semantics doesn't match exactly what I described.
> As for the original question - novops is internal only because its
> semantics is purely internal and changes with internal aliasing
> changes.
>
> Now, we still lack a compelling example to see what exact semantics
> you are requesting? I suppose it might be close to a pure but
> volatile function? Which you could simulate by
>
> dummy = pure_fn ();
> asm ("" : "g" (dummy));
>
> or even
>
> volatile int dummy = pure_fn ();
These two methods still generate extra code to reload variables
Bingfeng
>
> Richard.
>
> > Bingfeng
> >
> >> -Original Message-
> >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> >> Behalf Of Andrew Haley
> >> Sent: 12 April 2010 17:34
> >> To: gcc@gcc.gnu.org
> >> Subject: Re: Release novops attribute for external use?
> >>
> >> On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
> >> > Hello,
> >> > One of our engineers requested a feature so that
> >> > compiler can avoid to re-load variables after a function
> >> > call if it is known not to write to memory. It should
> >> > slash considerable code size in our applications. I found
> >> > the existing "pure" and "const" cannot meet his requirements
> >> > because the function is optimized out if it doesn't return
> >> > a value.
> >>
> >> If a function doesn't write to memory and it doesn't return a
> >> value, what is the point of calling it?
> >>
> >> Andrew.
> >>
> >>
> >
>
>
Re: Release novops attribute for external use?
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei wrote:
>>
>> Surely printf writes to global memory (it clobbers the stdout FILE*)
>>
> OK, the point is not about whether printf is pure or not. Instead, if
> programmer knows the callee function such as printf contains no
> memory access that affects operations inside caller function, and he
> would like to have a way to optimize the code. Our engineer gave following
> example:
>
> void myfunc(MyStruct *myStruct)
> {
> int a,b;
> a = myStruct->a;
> printf("a=%d\n",a);
> b = 2*mystruct->a; // I would like to have the compiler acting as
> if I had written b = 2*a;
> ...
> }
> Providing such attribute may be potentially dangerous. But it is just
> like "restrict" qualifier and some other attributes, putting responsibilty
> of correctness on the programmer. "novops" seems to achieve that effect,
> though its semantics doesn't match exactly what I described.
Indeed. IPA pointer analysis will probably figure it out
automagically - that *myStruct didn't escape the unit.
Being able to annotate incoming pointers this way would
maybe be useful.
>> As for the original question - novops is internal only because its
>> semantics is purely internal and changes with internal aliasing
>> changes.
>>
>> Now, we still lack a compelling example to see what exact semantics
>> you are requesting? I suppose it might be close to a pure but
>> volatile function? Which you could simulate by
>>
>> dummy = pure_fn ();
>> asm ("" : "g" (dummy));
>>
>> or even
>>
>> volatile int dummy = pure_fn ();
>
> These two methods still generate extra code to reload variables
The latter works for me (ok, the store to dummy is retained):
extern int myprintf(int) __attribute__((pure));
int myfunc (int *p)
{
int a;
a = *p;
volatile int dummy = myprintf(a);
return a + *p;
}
myfunc:
.LFB0:
pushq %rbx
.LCFI0:
subq$16, %rsp
.LCFI1:
movl(%rdi), %ebx
movl%ebx, %edi
callmyprintf
movl%eax, 12(%rsp)
leal(%rbx,%rbx), %eax
addq$16, %rsp
.LCFI2:
popq%rbx
.LCFI3:
ret
so we load from %rdi only once.
Richard.
> Bingfeng
>
>
>>
>> Richard.
>>
>> > Bingfeng
>> >
>> >> -Original Message-
>> >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> >> Behalf Of Andrew Haley
>> >> Sent: 12 April 2010 17:34
>> >> To: gcc@gcc.gnu.org
>> >> Subject: Re: Release novops attribute for external use?
>> >>
>> >> On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
>> >> > Hello,
>> >> > One of our engineers requested a feature so that
>> >> > compiler can avoid to re-load variables after a function
>> >> > call if it is known not to write to memory. It should
>> >> > slash considerable code size in our applications. I found
>> >> > the existing "pure" and "const" cannot meet his requirements
>> >> > because the function is optimized out if it doesn't return
>> >> > a value.
>> >>
>> >> If a function doesn't write to memory and it doesn't return a
>> >> value, what is the point of calling it?
>> >>
>> >> Andrew.
>> >>
>> >>
>> >
>>
>>
>
Re: Release novops attribute for external use?
On Tue, Apr 13, 2010 at 12:23 PM, Richard Guenther
wrote:
> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei wrote:
>>>
>>> Surely printf writes to global memory (it clobbers the stdout FILE*)
>>>
>> OK, the point is not about whether printf is pure or not. Instead, if
>> programmer knows the callee function such as printf contains no
>> memory access that affects operations inside caller function, and he
>> would like to have a way to optimize the code. Our engineer gave following
>> example:
>>
>> void myfunc(MyStruct *myStruct)
>> {
>> int a,b;
>> a = myStruct->a;
>> printf("a=%d\n",a);
>> b = 2*mystruct->a; // I would like to have the compiler acting as
>> if I had written b = 2*a;
>> ...
>> }
>> Providing such attribute may be potentially dangerous. But it is just
>> like "restrict" qualifier and some other attributes, putting responsibilty
>> of correctness on the programmer. "novops" seems to achieve that effect,
>> though its semantics doesn't match exactly what I described.
>
> Indeed. IPA pointer analysis will probably figure it out
> automagically - that *myStruct didn't escape the unit.
> Being able to annotate incoming pointers this way would
> maybe be useful.
>
>>> As for the original question - novops is internal only because its
>>> semantics is purely internal and changes with internal aliasing
>>> changes.
>>>
>>> Now, we still lack a compelling example to see what exact semantics
>>> you are requesting? I suppose it might be close to a pure but
>>> volatile function? Which you could simulate by
>>>
>>> dummy = pure_fn ();
>>> asm ("" : "g" (dummy));
>>>
>>> or even
>>>
>>> volatile int dummy = pure_fn ();
>>
>> These two methods still generate extra code to reload variables
>
> The latter works for me (ok, the store to dummy is retained):
>
> extern int myprintf(int) __attribute__((pure));
> int myfunc (int *p)
> {
> int a;
> a = *p;
> volatile int dummy = myprintf(a);
> return a + *p;
> }
>
> myfunc:
> .LFB0:
> pushq %rbx
> .LCFI0:
> subq $16, %rsp
> .LCFI1:
> movl (%rdi), %ebx
> movl %ebx, %edi
> call myprintf
> movl %eax, 12(%rsp)
> leal (%rbx,%rbx), %eax
> addq $16, %rsp
> .LCFI2:
> popq %rbx
> .LCFI3:
> ret
>
> so we load from %rdi only once.
And
extern int myprintf(int) __attribute__((pure));
int myfunc (int *p)
{
int a;
a = *p;
int dummy = myprintf(a);
asm ("" : : "g" (dummy));
return a + *p;
}
produces
myfunc:
.LFB0:
pushq %rbx
.LCFI0:
movl(%rdi), %ebx
movl%ebx, %edi
callmyprintf
leal(%rbx,%rbx), %eax
popq%rbx
.LCFI1:
ret
even better.
Richard.
RE: Release novops attribute for external use?
Thanks! I forgot to declare the function as pure. The empty asm
seems to be a clever trick to avoid function being optimized out.
I shall tell our engineers to use this instead of implementing a new
attribute.
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 13 April 2010 11:25
> To: Bingfeng Mei
> Cc: Andrew Haley; gcc@gcc.gnu.org
> Subject: Re: Release novops attribute for external use?
>
> On Tue, Apr 13, 2010 at 12:23 PM, Richard Guenther
> wrote:
> > On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei
> wrote:
> >>>
> >>> Surely printf writes to global memory (it clobbers the
> stdout FILE*)
> >>>
> >> OK, the point is not about whether printf is pure or not.
> Instead, if
> >> programmer knows the callee function such as printf contains no
> >> memory access that affects operations inside caller
> function, and he
> >> would like to have a way to optimize the code. Our
> engineer gave following
> >> example:
> >>
> >> void myfunc(MyStruct *myStruct)
> >> {
> >> int a,b;
> >> a = myStruct->a;
> >> printf("a=%d\n",a);
> >> b = 2*mystruct->a; // I would like to have the
> compiler acting as if I had written b = 2*a;
> >> ...
> >> }
> >> Providing such attribute may be potentially dangerous. But
> it is just
> >> like "restrict" qualifier and some other attributes,
> putting responsibilty
> >> of correctness on the programmer. "novops" seems to
> achieve that effect,
> >> though its semantics doesn't match exactly what I described.
> >
> > Indeed. IPA pointer analysis will probably figure it out
> > automagically - that *myStruct didn't escape the unit.
> > Being able to annotate incoming pointers this way would
> > maybe be useful.
> >
> >>> As for the original question - novops is internal only because its
> >>> semantics is purely internal and changes with internal aliasing
> >>> changes.
> >>>
> >>> Now, we still lack a compelling example to see what exact
> semantics
> >>> you are requesting? I suppose it might be close to a pure but
> >>> volatile function? Which you could simulate by
> >>>
> >>> dummy = pure_fn ();
> >>> asm ("" : "g" (dummy));
> >>>
> >>> or even
> >>>
> >>> volatile int dummy = pure_fn ();
> >>
> >> These two methods still generate extra code to reload variables
> >
> > The latter works for me (ok, the store to dummy is retained):
> >
> > extern int myprintf(int) __attribute__((pure));
> > int myfunc (int *p)
> > {
> > int a;
> > a = *p;
> > volatile int dummy = myprintf(a);
> > return a + *p;
> > }
> >
> > myfunc:
> > .LFB0:
> > pushq %rbx
> > .LCFI0:
> > subq $16, %rsp
> > .LCFI1:
> > movl (%rdi), %ebx
> > movl %ebx, %edi
> > call myprintf
> > movl %eax, 12(%rsp)
> > leal (%rbx,%rbx), %eax
> > addq $16, %rsp
> > .LCFI2:
> > popq %rbx
> > .LCFI3:
> > ret
> >
> > so we load from %rdi only once.
>
> And
>
> extern int myprintf(int) __attribute__((pure));
> int myfunc (int *p)
> {
> int a;
> a = *p;
> int dummy = myprintf(a);
> asm ("" : : "g" (dummy));
> return a + *p;
> }
>
> produces
>
> myfunc:
> .LFB0:
> pushq %rbx
> .LCFI0:
> movl(%rdi), %ebx
> movl%ebx, %edi
> callmyprintf
> leal(%rbx,%rbx), %eax
> popq%rbx
> .LCFI1:
> ret
>
> even better.
>
> Richard.
>
>
Re: Release novops attribute for external use?
On 13 April 2010 12:23, Richard Guenther wrote:
> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei wrote:
>>>
>>> Surely printf writes to global memory (it clobbers the stdout FILE*)
>>>
>> OK, the point is not about whether printf is pure or not. Instead, if
>> programmer knows the callee function such as printf contains no
>> memory access that affects operations inside caller function, and he
>> would like to have a way to optimize the code. Our engineer gave following
>> example:
>>
>> void myfunc(MyStruct *myStruct)
>> {
>> int a,b;
>> a = myStruct->a;
>> printf("a=%d\n",a);
>> b = 2*mystruct->a; // I would like to have the compiler acting as
>> if I had written b = 2*a;
>> ...
>> }
>> Providing such attribute may be potentially dangerous. But it is just
>> like "restrict" qualifier and some other attributes, putting responsibilty
>> of correctness on the programmer. "novops" seems to achieve that effect,
>> though its semantics doesn't match exactly what I described.
>
> Indeed. IPA pointer analysis will probably figure it out
> automagically - that *myStruct didn't escape the unit.
> Being able to annotate incoming pointers this way would
> maybe be useful.
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
isn't it?
Cheers,
Manuel.
Re: Release novops attribute for external use?
On Tue, Apr 13, 2010 at 1:35 PM, Manuel López-Ibáñez
wrote:
> On 13 April 2010 12:23, Richard Guenther wrote:
>> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei wrote:
Surely printf writes to global memory (it clobbers the stdout FILE*)
>>> OK, the point is not about whether printf is pure or not. Instead, if
>>> programmer knows the callee function such as printf contains no
>>> memory access that affects operations inside caller function, and he
>>> would like to have a way to optimize the code. Our engineer gave following
>>> example:
>>>
>>> void myfunc(MyStruct *myStruct)
>>> {
>>> int a,b;
>>> a = myStruct->a;
>>> printf("a=%d\n",a);
>>> b = 2*mystruct->a; // I would like to have the compiler acting as
>>> if I had written b = 2*a;
>>> ...
>>> }
>>> Providing such attribute may be potentially dangerous. But it is just
>>> like "restrict" qualifier and some other attributes, putting responsibilty
>>> of correctness on the programmer. "novops" seems to achieve that effect,
>>> though its semantics doesn't match exactly what I described.
>>
>> Indeed. IPA pointer analysis will probably figure it out
>> automagically - that *myStruct didn't escape the unit.
>> Being able to annotate incoming pointers this way would
>> maybe be useful.
>
> This is
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
>
> isn't it?
Not really.
Richard.
> Cheers,
>
> Manuel.
>
Re: fixed-point support in c++
On 3/19/10, Dave Korn wrote: > On 16/03/2010 09:15, Sean D'Epagnier wrote: > > Do you have a copyright assignment on file for GCC? For a non-trivial > contribution of this size, it's a requirement before the patch can be > accepted. > Yes this should be fine. > Once that is established, your patch would need a changelog entry in the > standard format, and you need to have built the compiler both patched and > clean and run a full C and C++ testsuite on both to check for regressions. I have not run the testsuite before, I have run "make check" on the latest svn gcc for C and C++ without any patches, and it fails: # of expected passes7052 # of unexpected failures1 # of expected failures 95 # of unsupported tests 341 Would the patch I have be ok if I get the same results? Or do I need to wait until there are no unexpected failures? Thanks Sean
Re: fixed-point support in c++
On 13/04/2010 16:06, Sean D'Epagnier wrote: > Would the patch I have be ok if I get the same results? Yes, absolutely; we insist only on no regressions, i.e. the patch mustn't increase the number of fails. Most targets have the odd outstanding failure or two. So there's no reason not to go ahead. Add a changelog entry, send your patch to the -patches list, and we'll see who we can get to review it. cheers, DaveK
branch probabilities on multiway branches
Hi All,
The following bit of code in predict.c implies branch probabilities
are strictly evenly distributed for multiway branches at present. The
comment suggests it is possible to generate better estimates for more
generic cases, apart from being involved. Could anyone point me to
the reference and/or if an implementation exists already.
/* When there is no successor or only one choice, prediction is easy.
We are lazy for now and predict only basic blocks with two outgoing
edges. It is possible to predict generic case too, but we have to
ignore first match heuristics and do more involved combining.
Implement
this later. */
if (nedges != 2)
{
if (!bb->count)
set_even_probabilities (bb);
clear_bb_predictions (bb);
if (dump_file)
fprintf (dump_file, "%i edges in bb %i predicted to even
probabilities\n",
nedges, bb->index);
return;
}
Many Thanks,
Rahul
Re: dragonegg in FSF gcc?
On 04/11/2010 06:26 PM, Duncan Sands wrote: 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 These do not seem to point at LLVM's optimizer bugs/aggressiveness, but rather at expressiveness of the IR. GENERIC benefited from years of working on the Ada front-end, and though it was indeed a good deal of work to iron out all the bugs, it is likely that a different compiler infrastructure does not have all the nuances. Paolo
Re: dragonegg in FSF gcc?
On 04/11/2010 06:50 PM, Dave Korn wrote: Grepping the -patches archives to see which platforms submitted patches get testing on would also be interesting, but somewhat harder owing to the more free-form nature of the text there. Still, a two-to-one ratio of linux to rest-of-the-world would be in line with my subjective impression: it's not overwhelming the rest, but it's substantially the best tended-to. The fact that testing under Cygwin is so much slower certainly has an impact. A lot of people used to develop under Darwin, but unfortunately it tended to break quite often, and it often became very hard to bootstrap without the latest Mac OS X and Xcode. The fact that Apple is not maintaining the port anymore didn't help, as Jack knows. Paolo
Re: dragonegg in FSF gcc?
On 04/12/2010 04:18 PM, Dave Korn wrote: Could anyone really believe that without being a grade A tinfoil-hat wearing crazy? More precisely, could anyone capable of the kind of rational thought processes that they'd need to have in order to be able to make any kind of contribution to the GCC project really believe that? I'm not convinced that we need to worry much about what generic non-contributing internet kooks, trolls and idiots think. Unfortunately there is a great deal of people that are ready to drop sh*t on projects just because they are copyleft, and that doesn't help GCC. Of course, those are the same people that wonder "why" when a random company promises contributing some cool technology to a BSD-licensed project, and then changes their mind. We can indeed choose to ignore trolls; still, they exist. Paolo
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 07:05:17PM +0200, Paolo Bonzini wrote: > On 04/12/2010 04:18 PM, Dave Korn wrote: >> Could anyone really believe that without being a grade A tinfoil-hat >> wearing crazy? More precisely, could anyone capable of the kind of >> rational thought processes that they'd need to have in order to be >> able to make any kind of contribution to the GCC project really >> believe that? I'm not convinced that we need to worry much about >> what generic non-contributing internet kooks, trolls and idiots >> think. > > Unfortunately there is a great deal of people that are ready to drop > sh*t on projects just because they are copyleft, and that doesn't help GCC. > > Of course, those are the same people that wonder "why" when a random > company promises contributing some cool technology to a BSD-licensed > project, and then changes their mind. > > We can indeed choose to ignore trolls; still, they exist. Paolo, I hope you don't think I was trolling in my initial post. Assuming plugins will eventually be welcomed into the FSF gcc source tree in general, there is a valid argument for having dragon-egg present with a configure option that builds it if the proper llvm is available. Jack > > Paolo
Re: dragonegg in FSF gcc?
On 04/13/2010 07:14 PM, Jack Howarth wrote: Paolo, I hope you don't think I was trolling in my initial post. Assuming plugins will eventually be welcomed into the FSF gcc source tree in general, there is a valid argument for having dragon-egg present with a configure option that builds it if the proper llvm is available. I was absolutely not thinking of anyone in this thread. FWIW, my opinion is that I think it would be nice to have dragonegg build out-of-the-box with FSF GCC (and I would very much welcome that my distro applied the patch, if not) however I don't see a reason to have it live in the FSF repository. On the other hand, I would welcome a gcc-clang front-end in the FSF repository. 16 months ago I probably would have even given it a shot. Paolo
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 7:14 PM, Jack Howarth wrote: > I hope you don't think I was trolling in my initial post. Assuming > plugins will eventually be welcomed into the FSF gcc source tree in > general, there is a valid argument for having dragon-egg present with > a configure option that builds it if the proper llvm is available. There are already plugins in the FSF gcc source tree. Well, OK, just one (lto-plugin) but there aren't very many plugins at the moment that are suitable for inclusion in the FSF tree (i.e. not as tightly tied to a GCC feature that GCC itself can't work fully without it). IMHO the nature of the DragonEgg plugin makes it unsuitable for inclusion in the FSF gcc source tree, ever. Ciao! Steven
Re: specs question.
On 04/12/2010 07:01 PM, IainS wrote: > > It clearly depends on something no-obvious. > > gcc hello.c -g -o hc => dsymutils gets run (not expected from the > syntax, assuming that sources are irrelevant) > > gcc hello.o -g -o hc => no dsymutils (expected from the absence of '.o' > in the list) Hi Iain, We don't want to run dsymutil if there are .o files, let the developer do that. If someone just does gcc -g -o foo foo.c, then any debugging information will be lost when the temporary .o file is removed, thus, to allow debugging such a foo, the compiler must run dsymutil. Of course, it doesn't need to run for stabs, or -g0. Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion of the specs appears identical. Peter
Copy assignments for non scalar types
Hi, While working on the tree-if-conv.c, I realized that the copy of the contents of a non scalar variable are not correctly done. The copy assignment triggers this error: error: virtual SSA name for non-VOP decl while verifying SSA_NAME _ifc_.2005_46 in statement # .MEM_394 = VDEF <.MEM_475> _ifc_.2005_46 = ops[j_457]; The array reference looks like this:
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 07:18:12PM +0200, Paolo Bonzini wrote: > On 04/13/2010 07:14 PM, Jack Howarth wrote: >> Paolo, >> I hope you don't think I was trolling in my initial post. Assuming >> plugins will eventually be welcomed into the FSF gcc source tree in >> general, there is a valid argument for having dragon-egg present with >> a configure option that builds it if the proper llvm is available. > > I was absolutely not thinking of anyone in this thread. > > FWIW, my opinion is that I think it would be nice to have dragonegg > build out-of-the-box with FSF GCC (and I would very much welcome that my > distro applied the patch, if not) however I don't see a reason to have > it live in the FSF repository. Paolo, It is unclear to me what the original intentions were when the plugin infrastructure was created. That is, was it envisioned that FSF could accumulate the plugins directly in the source tree to ensure they were well maintained across FSF gcc releases? Jack > > On the other hand, I would welcome a gcc-clang front-end in the FSF > repository. 16 months ago I probably would have even given it a shot. > > Paolo
Re: specs question.
On 13 Apr 2010, at 19:05, Peter O'Gorman wrote:
gcc hello.c -g -o hc => dsymutils gets run (not expected from the
syntax, assuming that sources are irrelevant)
gcc hello.o -g -o hc => no dsymutils (expected from the absence of
'.o'
in the list)
We don't want to run dsymutil if there are .o files, let the developer
do that.
OK, although AFAICT,
it should be harmless doing it in the general case (and, to some
extent, more friendly).
If someone just does gcc -g -o foo foo.c, then any debugging
information
will be lost when the temporary .o file is removed, thus, to allow
debugging such a foo, the compiler must run dsymutil.
That's understood - although see below for a comment on Fortran***.
Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion
of the specs appears identical.
indeed - although of course there's no reason to suppose that gcc/
gcc.c is identical in the two cases (I can check that at some stage)
My question has more to do with whether the apparent intention of the
spec is being honored..
... and also why it doesn't work if I add more extensions (e.g. to
extend coverage to Fortran, which Apple are not trying to cover in
their case).
[***Even if I remove the %{.xxx.xxx.xx: } in the dsyutil section,
there's a subsidiary issue with the Fortran case in that the debug
info is only working if I put -save-temps on the CL].
cheers,
Iain
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher wrote: > There are already plugins in the FSF gcc source tree. Well, OK, just > one (lto-plugin) but there aren't very many plugins at the moment that > are suitable for inclusion in the FSF tree (i.e. not as tightly tied > to a GCC feature that GCC itself can't work fully without it). Except lto-plugin is a plugin for the gold linker and not for GCC. Oh and the linker has a more stable ABI already because of the way plugins are implemented there. I think most plugins should be done just to experiment with and real passes should become integrated fully and not a plugin at all. This was the same argument I had the last time about plugin database. > > IMHO the nature of the DragonEgg plugin makes it unsuitable for > inclusion in the FSF gcc source tree, ever. It belongs with LLVM sources if anywhere. Thanks, Andrew Pinski
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 12:21:09PM -0700, Andrew Pinski wrote: > On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher > wrote: > > There are already plugins in the FSF gcc source tree. Well, OK, just > > one (lto-plugin) but there aren't very many plugins at the moment that > > are suitable for inclusion in the FSF tree (i.e. not as tightly tied > > to a GCC feature that GCC itself can't work fully without it). > > Except lto-plugin is a plugin for the gold linker and not for GCC. Oh > and the linker has a more stable ABI already because of the way > plugins are implemented there. > > I think most plugins should be done just to experiment with and real > passes should become integrated fully and not a plugin at all. This > was the same argument I had the last time about plugin database. > > > > > IMHO the nature of the DragonEgg plugin makes it unsuitable for > > inclusion in the FSF gcc source tree, ever. > > It belongs with LLVM sources if anywhere. I think the idea was that it would live in both repositories. The dragon-egg in FSF gcc would be focused on using the stable llvm and adapting to the FSF gcc trunk changes. The dragon-egg in llvm would use the stable gcc release and be focused on adapting to llvm trunk changes. The two could be re-merged on each llvm or gcc release. My view anyway. Jack > > Thanks, > Andrew Pinski
Re: dragonegg in FSF gcc?
On 04/13/2010 09:16 PM, Jack Howarth wrote: Paolo, It is unclear to me what the original intentions were when the plugin infrastructure was created. That is, was it envisioned that FSF could accumulate the plugins directly in the source tree to ensure they were well maintained across FSF gcc releases? Not really. Plugins were added for people to be able to extend GCC in novel ways. It was clear that some of these would circumvent GCC's copyleft, and so the runtime license exception was devised. In this sense, dragonegg is not harmful to GCC; if you wrote a proprietary LLVM pass, the result would be not eligible for the runtime license exception. However, I think there is another reason why dragonegg belongs in the LLVM repository. It is very unlikely to be used by anyone who has no interest in LLVM, and vice versa many LLVM users will want to try it out. GCC developers who otherwise won't use LLVM are the exception, in my opinion. Similarly, if a gcc-clang existed it would belong in the FSF repository (probably on a branch) because (I think) hardly any LLVM user would be interested in it. Paolo
Re: Copy assignments for non scalar types
On Tue, Apr 13, 2010 at 01:14:11PM -0500, Sebastian Pop wrote:
> /* Create a new temp variable of type TYPE. Add GIMPLE_ASSIGN to assign EXP
>to the new variable. */
>
> static gimple
> ifc_temp_var (tree type, tree exp)
> {
> const char *name = "_ifc_";
> tree var, new_name;
> gimple stmt;
>
> /* Create new temporary variable. */
> var = create_tmp_var (type, name);
> add_referenced_var (var);
>
> /* Build new statement to assign EXP to new variable. */
> stmt = gimple_build_assign (var, exp);
>
> /* Get SSA name for the new variable and set make new statement
> its definition statement. */
> new_name = make_ssa_name (var, stmt);
> gimple_assign_set_lhs (stmt, new_name);
> SSA_NAME_DEF_STMT (new_name) = stmt;
> update_stmt (stmt);
>
> return stmt;
> }
>
> What is missing in this function to make it handle non scalar types?
if (!is_gimple_reg (var))
you shouldn't create SSA name and change the lhs of the stmt.
Jakub
Re: Copy assignments for non scalar types
On Tue, Apr 13, 2010 at 13:14, Sebastian Pop wrote:
> Hi,
>
> While working on the tree-if-conv.c, I realized that the copy
> of the contents of a non scalar variable are not correctly done.
> The copy assignment triggers this error:
>
> error: virtual SSA name for non-VOP decl
> while verifying SSA_NAME _ifc_.2005_46 in statement
> # .MEM_394 = VDEF <.MEM_475>
> _ifc_.2005_46 = ops[j_457];
>
> The array reference looks like this:
>
> type sizes-gimplified asm_written type_0 BLK
>
> For scalar types, the code that creates the copy is working correctly:
>
> /* Create a new temp variable of type TYPE. Add GIMPLE_ASSIGN to assign EXP
> to the new variable. */
>
> static gimple
> ifc_temp_var (tree type, tree exp)
> {
> const char *name = "_ifc_";
> tree var, new_name;
> gimple stmt;
>
> /* Create new temporary variable. */
> var = create_tmp_var (type, name);
> add_referenced_var (var);
>
> /* Build new statement to assign EXP to new variable. */
> stmt = gimple_build_assign (var, exp);
>
> /* Get SSA name for the new variable and set make new statement
> its definition statement. */
> new_name = make_ssa_name (var, stmt);
> gimple_assign_set_lhs (stmt, new_name);
> SSA_NAME_DEF_STMT (new_name) = stmt;
> update_stmt (stmt);
>
> return stmt;
> }
>
> What is missing in this function to make it handle non scalar types?
>
At least this is missing (but it is not enough, so I am still looking for
a solution):
if (gimple_referenced_vars (cfun))
{
add_referenced_var (t);
mark_sym_for_renaming (t);
}
from tree-dfa.c:
/* Build a temporary. Make sure and register it to be renamed. */
tree
make_rename_temp (tree type, const char *prefix)
{
tree t = create_tmp_var (type, prefix);
if (TREE_CODE (TREE_TYPE (t)) == COMPLEX_TYPE
|| TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
DECL_GIMPLE_REG_P (t) = 1;
if (gimple_referenced_vars (cfun))
{
add_referenced_var (t);
mark_sym_for_renaming (t);
}
return t;
}
I will replace the call to create_tmp_var with make_rename_temp.
Sebastian
Re: Copy assignments for non scalar types
On Tue, Apr 13, 2010 at 14:42, Jakub Jelinek wrote: > if (!is_gimple_reg (var)) > > you shouldn't create SSA name and change the lhs of the stmt. > This worked well. Thanks Jakub! Sebastian
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 15:16, Jack Howarth wrote: > It is unclear to me what the original intentions were when the > plugin infrastructure was created. That is, was it envisioned that > FSF could accumulate the plugins directly in the source tree to > ensure they were well maintained across FSF gcc releases? My idea was (and still is) that we could host a directory of available plugins, but each plugin would be a separate project with its own schedules, home pages and source trees. The directory is hosted at http://gcc.gnu.org/wiki/plugins. Dragonegg is already there. The plugin API will likely be very volatile at first, but it may converge at some point. Personally, I would love to see DragonEgg used to bridge between gcc and llvm. This will bring lots of benefits to both compilers, since we'll be able to easily compare and take from each other. Diego.
Re: Copy assignments for non scalar types
> if (!is_gimple_reg (var)) > > you shouldn't create SSA name and change the lhs of the stmt. You might also not be allowed to make a copy in the first place but only to take a reference, see gimplify_cond_expr. -- Eric Botcazou
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 10:19 PM, Diego Novillo wrote: > Personally, I would love to see DragonEgg used to bridge between gcc > and llvm. This will bring lots of benefits to both compilers, since > we'll be able to easily compare and take from each other. You say you see benefits for both compilers. What benefits do you see for GCC then, if I may ask? And what can GCC take from LLVM? (And I mean the FSF GCC, long term.) This is an honest question, because I personally really don't see any benefit for GCC. Ciao! Steven
Testing GCC on Cygwin made substantially easier [was Re: dragonegg in FSF gcc?]
On 13/04/2010 17:57, Paolo Bonzini wrote: > The fact that testing under Cygwin is so much slower certainly has an > impact. It gets more manageable at -j levels, but there's an underlying bug in the Cygwin DLL's process info management that causes expect to fall into cpu-spinning lockups and cascading process fork collapse syndrome. Until I find time to do a more major rewrite, anyone who wants to do testing on Cygwin could do worse than apply the sticking-plaster patch that I posted at: http://www.mail-archive.com/cygwin-patc...@cygwin.com/msg04677.html and build themselves a locally modified version of the Cygwin DLL that will happily run make check at significant -j levels (I think I tried 12 at most; I've only got a dual-core cpu so it wasn't exactly efficient, but it proved that the patch holds up under substantial load). cheers, DaveK
Re: dragonegg in FSF gcc?
On Tue, Apr 13, 2010 at 16:51, Steven Bosscher wrote: > You say you see benefits for both compilers. What benefits do you see > for GCC then, if I may ask? And what can GCC take from LLVM? (And I > mean the FSF GCC, long term.) This is an honest question, because I > personally really don't see any benefit for GCC. If comparisons between the two compilers are easy to make, then it's easy to determine what one compiler is doing better than the other and do the necessary port. In terms of internal structure, LLVM is more modular, which simplifies maintenance (e.g., the automatic bug finder, unit tests). The various components of the pipeline have better separation and stronger APIs. GCC has been slowly moving in that direction, but it still have ways to go. LLVM has already proven that organizing the compiler that way is advantageous (additionally, other research compilers were structured similarly: Sage++, SUIF), so emulating that structure sounds like a reasonable approach. Another example where GCC may want to operate with LLVM is in JIT compilation. Clearly, LLVM has made a significant investment in this area. If GCC were to generate LLVM IR, it could just use all the JIT machinery without having to replicate it. There may be other things GCC could take advantage of. OTOH, GCC has optimizer and codegen features that LLVM may want to incorporate. I don't have specific examples, since I am not very familiar with LLVM. Diego.
Re: may_be_unaligned_p bug?
> I tested trunk and an old 4.2.1 internal branch, and found the bug on > both, so anything in between would be affected too. It goes back at > least to this patch, which mostly fixed the bug: > > 2008-02-19 Christian Bruel > Zdenek Dvorak > > * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Check step alignment. OK, I tested it (a little) with trunk on SPARC/Solaris and SPARC64/Solaris and things look good as well. I won't be able to do a formal submission before at least one week so if you feel like beating me to it, go ahead. -- Eric Botcazou
-fexceptions introduces ABI incompatibility of sorts (was: RE: Re[2]: [Gc] On cancellation, GC_thread_exit_proc is never called)
I would still love to get a reaction to this from the gcc folks (now included): 1) Is it intended that inconsistent use of -fexceptions can cause pthread cleanup handlers to be skipped (since exception based cleanup is not invoked if thread exit is triggered from a context without exceptions), thus usually breaking code relying on pthread_cleanup handlers? 2) If so, would it be appropriate to document that behavior? In particular, several other options in the gcc manual currently indicate that they introduce binary compatibility issues, while this one does not. This does seem to be basically a binary incompatibility issue. 3) If not, any chance of fixing this somehow? 4) Is the use of the __EXCEPTIONS macro in the library considered a stable part of the library interface? Is it reasonable to work around this problem by explicitly undefining it in user code? The original problem description that triggered this discussion can be found at http://permalink.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3820 Thanks. Hans > -Original Message- > From: gc-boun...@napali.hpl.hp.com > [mailto:gc-boun...@napali.hpl.hp.com] On Behalf Of Ivan Maidanski > Sent: Saturday, April 10, 2010 6:20 AM > To: NIIBE Yutaka > Cc: g...@napali.hpl.hp.com > Subject: Re[2]: [Gc] On cancellation, GC_thread_exit_proc is > never called > > > Fri, 09 Apr 2010 17:45:47 +0900 NIIBE Yutaka : > > > Ivan Maidanski wrote: > > > This seems to be equivalent to your first patch. > > > > It is equivalent for libgc build, but it doesn't touch any header > > files. > > > > My intention is to minimize impact by the change. > > > > For libgc users who include gc.h, the first/second patch of > mine would > > not be good. Even if a user use -fexceptions for her > application, the > > change of undefine __EXCEPTIONS forces to use > __pthread_register_cancel. > > With third patch, it is up to users. > > > > > Did you read > > > > http://permalink.gmane.org/gmane.comp.programming.garbage-collection > > > .boehmgc/3824 ? Why not to pull GC_inner_start_routine > out into a > > > separate file that isn't compiled with -fexceptions? > > > > Thanks for the pointer. I had not read it. I read it now. > > > > My opinion is that: > > > > (1) I would agree that it would be better to pull out > > GC_inner_start_routine into a separate file. > > > > Just FYI, I confirmed that it is not needed to separate it out, > > at least for current implementation. > > > > For current implementation, compilation of > pthread_support.c with > > no __EXCEPTIONS only affects compilation of > GC_inner_start_routine > > (specifically, pthread_cancel_push), no effect for > other routines. > > > > (2) Only undefining __EXCEPTIONS is better, I think. > > > > I think that compiling GC_inner_start_routine without > -fexceptions > > is overkill somehow. Yes, it means it goes with no > __EXCEPTIONS, > > but it also generates no .eh_frame section for > > GC_inner_start_routine. > > > > No .eh_frame section for GC_inner_start_routine would be OK, > > because it is almost starting point of a thread. > > > > One minor benefit: If we have .eh_frame section for > > GC_inner_start_routine, it is possible for a debugger to trace > > back to the beginning. This is perhaps only useful > for those who > > chase down to the detail of pthread_create > implementation, though. > > -- > > I could agree with You. But, again, it's up to Hans whether > to commit this patch or not. > > Bye. > ___ > Gc mailing list > g...@linux.hpl.hp.com > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/ >
The Linux binutils 2.20.51.0.8 is released
This is the beta release of binutils 2.20.51.0.8 for Linux, which is
based on binutils 2010 0412 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.gold will be installed as ld. You can use the configure
option, --enable-gold=both/bfd to choose bfd ld as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/bfd --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.20.51.0.8 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.20.51.0.7:
1. Update from binutils 2010 0412.
2. Don't bind unique symbol locally. PR 11434.
3. Add DWARF 4 support to linker and readelf.
4. Fix --no-export-dynamic for PIE. PR 11413.
5. Speed up x86 assembler.
6. Use memmove instead of memcpy to copy overlap memory in assembler.
PR 11456.
7. Improve gold.
8. Improve VMS support.
9. Improve PE support.
10. Add TI C6X support.
11. Improve arm support.
12. Improve cris support.
13. Improve ppc support.
Changes from binutils 2.20.51.0.6:
1. Update from binutils 2010 0318.
2. Don't set ELFOSABI_LINUX for undefined STT_GNU_IFUNC symbols.
3. Improve x86 assembler error messages.
4. Support vpermilp[ds] for x86.
5. Fix strip for group sections.
6. Fix objcopy for PE PIE. PR 11396.
7. Avoid 32bit overflow in linker.
8. Correct backslash quote logic in assembler. PR 11356.
9. Improve linker --section-start support. PR 11304.
10. Properly update LMA. PR 11219.
11. Don't combine .init_array/.fini_array sections for relocatable link.
12. Add Solaris Sparc/x86 linker support.
13. Support dumping .ARM.exidx/.ARM.extab.
14. Add STT_GNU_IFUNC support for Sparc.
15. Improve gold.
16. Improve arm support.
17. Improve avr support.
18. Improve mips support.
19. Improve ppc support.
20. Improve xtensa support.
Changes from binutils 2.20.51.0.5:
1. Update from binutils 2010 0205.
2. Support x86 XSAVE extended state core dump.
3. Add an option, -mavxscalar=, to x86 assembler to encoding AVX
scalar instructions with VL=256 and update x86 disassembler.
4. Add xsave64/xrstor64 to x86 assembler/disassembler.
5. Add all the possible aliases for VPC
gcc-4.4-20100413 is now available
Snapshot gcc-4.4-20100413 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100413/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 158282 You'll find: gcc-4.4-20100413.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100413.tar.bz2 C front end and core compiler gcc-ada-4.4-20100413.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100413.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100413.tar.bz2 C++ front end and runtime gcc-java-4.4-20100413.tar.bz2 Java front end and runtime gcc-objc-4.4-20100413.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100413.tar.bz2The GCC testsuite Diffs from 4.4-20100406 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: dragonegg in FSF gcc?
On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth wrote: > Rather than viewing dragon-egg as some sort > of lamprey which is feeding off of the FSF gcc project, > we should welcome the competition from a direct comparison > of alternative back/middle ends (not fear it). 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? However, I found your posting of "llvm-gfortran" Polyhedron comparisons of different LLVM versions (http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030799.html). But that comparison does not including gfortran results. I also found comparisons of llvm-gfortran and FSF gfortran (http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015441.html and http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025119.html). But unfortunately I can't find these results posted on the GCC fortran mailing list, or Bugzilla bug reports for cases where llvm-gfortran performed better than FSF gfortran. So there's not much benefit from these comparisons for GCC. Where these results generated using DragonEgg? Or can you make these comparisons without DragonEgg too? > One could also make an argument that it is in the best > interest of FSF gcc to do so. Isn't better to keep all > of the alternative front-end developers (gfortran, ada, > etc) within the FSF gcc tent rather than forcing the > creation of competing clang fortran and ada projects. Why would that be better? And, why would that be better only for the front ends, but not for the middle ends and back ends? You don't seem to have a problem with the creation of competing back ends. If you so believe in competition between compilers, then why are you against competition at the level of front ends? You should encourage a clang fortran project. But apparently, you don't. That doesn't look like a desire for competition or comparisons, but only a desire to rip the parts of GCC that LLVM doesn't already provide itself. Ciao! Steven
Re: dragonegg in FSF gcc?
On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote: > On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth > wrote: > > Rather than viewing dragon-egg as some sort > > of lamprey which is feeding off of the FSF gcc project, > > we should welcome the competition from a direct comparison > > of alternative back/middle ends (not fear it). > > 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? > > > However, I found your posting of "llvm-gfortran" Polyhedron > comparisons of different LLVM versions > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030799.html). > But that comparison does not including gfortran results. > > I also found comparisons of llvm-gfortran and FSF gfortran > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015441.html and > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025119.html). > But unfortunately I can't find these results posted on the GCC fortran > mailing list, or Bugzilla bug reports for cases where llvm-gfortran > performed better than FSF gfortran. So there's not much benefit from > these comparisons for GCC. > > Where these results generated using DragonEgg? Or can you make these > comparisons without DragonEgg too? Those benchmarks were made with just the stock gfortran from the llvm-gcc-4.2 source tree from the release_27 branch. Of course, the benchmarks for gcc 4.5 (or gcc 4.4) are signficantly faster (gcc 4.2.1 isn't the best release to be trapped on for gfortran performance). On the same machine, I am seeing these numbers for the gcc 4.5 release... Date & Time : 25 Mar 2010 0:08:05 Test Name : gfortran_lin_p4 Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats :10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 0.86 1 10.59 10 0.0069 aermod 39.15 1 21.35 10 0.0086 air 2.24 1 5.68 12 0.0392 capacita 1.70 1 33.19 10 0.0110 channel 0.56 1 1.83 10 0.0257 doduc 4.58 1 27.72 10 0.0122 fatigue 1.54 1 8.04 10 0.0382 gas_dyn 2.83 1 4.39 18 0.0965 induct 3.55 1 12.67 10 0.0127 linpk 0.70 1 15.41 10 0.0458 mdbx 1.51 1 11.33 10 0.0059 nf 1.90 1 27.96 17 0.0967 protein 3.48 1 37.02 10 0.0058 rnflow 5.20 1 23.64 10 0.0243 test_fpu 4.19 1 8.68 10 0.0494 tfft 0.49 1 1.88 10 0.0766 Geometric Mean Execution Time = 11.27 seconds I intend to do some benchmarks with dragon-egg shortly. At the moment, I am finishing up a gcc45 fink package capable of building dragon-egg. My goal is to have fink packages for gcc45, llvm-2.7 and current dragon-egg so that everything can be tested against the other. My current plan is to have compiler wrappers, degcc-4, etc, which will automatically call the plugin. It will be particularly interesting to see how dragon-egg manages libLTO usage. Hopefully by gcc-4.5.1 we will have the Mach-O LTO working and some direct comparisons can be made between the two. Jack > > > > One could also make an argument that it is in the best > > interest of FSF gcc to do so. Isn't better to keep all > > of the alternative front-end developers (gfortran, ada, > > etc) within the FSF gcc tent rather than forcing the > > creation of competing clang fortran and ada projects. > > Why would that be better? And, why would that be better only for the > front ends, but not for the middle ends and back ends? You don't seem > to have a problem with the creation of competing back ends. If you so > believe in competition between compilers, then why are you against > competition at the level of front ends? You should encourage a clang > fortran project. > > But apparently, you don't. That doesn't look like a desire for > competition or comparisons, but only a desire to rip the parts of GCC > that LLVM doesn't already provide itself. > > Ciao! > Steven
Re: branch probabilities on multiway branches
> Hi All, > > The following bit of code in predict.c implies branch probabilities > are strictly evenly distributed for multiway branches at present. The > comment suggests it is possible to generate better estimates for more > generic cases, apart from being involved. Could anyone point me to > the reference and/or if an implementation exists already. There is Wu & Larus paper cited in the comment at the begging of file. Honza
Re: -fexceptions introduces ABI incompatibility of sorts (was: RE: Re[2]: [Gc] On cancellation, GC_thread_exit_proc is never called)
"Boehm, Hans" writes: > 1) Is it intended that inconsistent use of -fexceptions can cause > pthread cleanup handlers to be skipped (since exception based > cleanup is not invoked if thread exit is triggered from a context > without exceptions), thus usually breaking code relying on > pthread_cleanup handlers? I don't know if I would use the word "intended," but I think this is an expected and unavoidable consequence. > 2) If so, would it be appropriate to document that behavior? In > particular, several other options in the gcc manual currently > indicate that they introduce binary compatibility issues, while this > one does not. This does seem to be basically a binary > incompatibility issue. Well, properly speaking, I don't think there is any binary incompatibility in what gcc generates. Code compiled with and without -fexceptions can interoperate perfectly well. I can see that the way in which glibc uses _EXCEPTIONS to decide how to handle pthread cleanups introduces an incompatibility, but I think that is more an issue of how the compiler is being used. Of course more documentation is normally good, but in this case what would the new documention say? It seems that it would amount to something like "If you compile code without exception support, then any exception handlers in that code will not be run." It seems almost tautological. I'm not trying to pick nits here. glibc has chosen to implement a cleanup mechanism which assumes that the code is compiled entirely with or entirely without exception support. That's a choice made by the glibc maintainers, and any restrictions that imposes are part of glibc, not gcc. gcc is, of course, used with libraries other than glibc, which may or may not have similar problems. I think gcc is making a reasonable choice in permitting exceptions to be enabled or disabled as the user prefers. > 3) If not, any chance of fixing this somehow? I don't really see how. Do you have any suggestions? > 4) Is the use of the __EXCEPTIONS macro in the library considered a > stable part of the library interface? Is it reasonable to work > around this problem by explicitly undefining it in user code? gcc will reliably define _EXCEPTIONS as 1 when exceptions are supported, and will reliably not define _EXCEPTIONS when exceptions are not supported. I can't speak to the library interface. Ian
Re: RFC: c++ diagnostics
On 5 April 2010 17:20, Benjamin Kosnik wrote: > > Included are most of the outstanding bugzilla requests with the > "diagnostic" keyword. However, I am looking for help! Please send me > code samples that frustrate, obfuscate, and annoy. Some PRs missing in this list: 986 13452 13657 15766 16663 17459 23263 31423 36888 37200 39858 39859 43275 And these are only about errors. There are a lot more about warnings. On the other hand, PR 43431 is marked as fixed, it is not a parsing problem and i think it should be removed. Again, links in the PR numbers would help to check the status of the PRs listed in the webpage. Cheers, Manuel.
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.
vectorization, scheduling and aliasing
Hi All,
I have implemented some vectorization features in my gcc port.
In the generated code for this function I can see a scheduling problem:
int xxx(int* __restrict__ a, int* __restrict__ b)
{
int __restrict__ i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
return 0;
}
from asmcons:
(insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
(mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
(insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
(reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
(nil)))
(insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
(mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
(const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
(expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
(nil)))
(insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
(const_int 8 [0x8])) [2 S8 A64])
(reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
(expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
(nil
from sched1 - dependecies list:
--- Region Dependences --- b 3 bb 0
;; insn codebb dep prio cost reservation
;; -- --- ---
;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
;; 20 116 3 2 1 1 (2_slots+lsu) : 58
;; 58 101 3 4 1 1 (3_slots+pcu) :
As you can see, insn 19 is dependant on 18.
I think that this should not happen since the arrays has __restrict__.
It might have something to do with aliasing.
Are you aware of any kind of problems regarding aliasing and vectors?
Can you think of anything else that might be wrong in my code that
leads gcc to think that there is a dependency between insn 18 and 19?
Thanks, Roy.
