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;
}
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
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
"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_clea
> 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
> t
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
> >
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 al
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
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
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),
> 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_b
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 a
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
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 compil
> 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
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 FS
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
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 S
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
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
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 incl
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 GC
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
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 argume
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>
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 lis
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 build
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
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
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 pro
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
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/aggr
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 a
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
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, you
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
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
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.
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 calle
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
>
> 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
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 ca
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
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
44 matches
Mail list logo
