Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] dragonegg FSF gcc merge?"
2010 Apr 09
0
[LLVMdev] dragonegg FSF gcc merge?
Hi Jack,
> Is there a timeline for when dragonegg might be
> merged into gcc (4.6 perhaps)? I ask because FSF gcc
> has allowed code in as technology previews before.
> For instance, graphite really wasn't that usable in
> gcc 4.4 and produced wrong code in the Polyhedron
> 2005 benchmarks until gcc 4.5. So as long as it can bootstrap
> gcc 4.6 and works in general,
2010 Apr 09
3
[LLVMdev] dragonegg FSF gcc merge?
On Fri, Apr 09, 2010 at 04:14:17PM +0200, Duncan Sands wrote:
> Hi Jack,
>
> > Is there a timeline for when dragonegg might be
> > merged into gcc (4.6 perhaps)? I ask because FSF gcc
> > has allowed code in as technology previews before.
> > For instance, graphite really wasn't that usable in
> > gcc 4.4 and produced wrong code in the Polyhedron
>
2010 Apr 09
3
[LLVMdev] dragonegg FSF gcc merge?
On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote:
> Hi Jack,
>
>>>> Is there a timeline for when dragonegg might be
>>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc
>>>> has allowed code in as technology previews before.
>>>> For instance, graphite really wasn't that usable in
>>>> gcc 4.4 and produced
2010 Apr 09
0
[LLVMdev] dragonegg FSF gcc merge?
Hi Jack,
>>> Is there a timeline for when dragonegg might be
>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc
>>> has allowed code in as technology previews before.
>>> For instance, graphite really wasn't that usable in
>>> gcc 4.4 and produced wrong code in the Polyhedron
>>> 2005 benchmarks until gcc 4.5. So as long as it
2010 Apr 09
0
[LLVMdev] dragonegg FSF gcc merge?
On Fri, Apr 9, 2010 at 9:30 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote:
>> Hi Jack,
>>
>>>>> Is there a timeline for when dragonegg might be
>>>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc
>>>>> has allowed code in as technology previews
2012 Apr 03
0
[LLVMdev] pb05 results for current llvm/dragonegg
Hi Jack,
> Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn
> on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3.
thanks for the numbers. How does this compare to LLVM 3.0 - were there any
regressions?
Ciao, Duncan.
The benchmarks
> for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate
> since
2012 Apr 02
6
[LLVMdev] pb05 results for current llvm/dragonegg
Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn
on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. The benchmarks
for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate
since there seems to be a bug in -msse4 on 2.33 GHz (T7600) Intel Core 2 Duo Merom
(http://llvm.org/bugs/show_bug.cgi?id=12434).
2011 Sep 06
2
[LLVMdev] major dragonegg improvement
I'm not certain yet which commit in the last couple of days caused this,
but the current llvm/dragonegg svn shows a major improvement in the runtime
of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the
dragonegg plugin at -O3 -ffast-math -funroll-loops. Previously the xplor-nih
testsuite always executed in ~40 sec but now it is coming it at 34.5 sec which
is about the
2012 Apr 03
3
[LLVMdev] pb05 results for current llvm/dragonegg
On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote:
> Hi Jack,
>
>> Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn
>> on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3.
>
> thanks for the numbers. How does this compare to LLVM 3.0 - were there any
> regressions?
The results from just before
2012 Apr 03
0
[LLVMdev] pb05 results for current llvm/dragonegg
On Tue, 3 Apr 2012 08:57:51 -0400
Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote:
> > Hi Jack,
> >
> >> Attached are the Polyhedron 2005 benchmark results for current
> >> llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode
> >> 4.3.2 and FSF gcc 4.6.3.
> >
>
2012 Dec 09
3
[LLVMdev] pb05 benchmarks for llvm/dragonegg 3.2
Duncan,
With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html,
the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what
were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05)
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044091.html.
Jack
2013 May 09
4
[LLVMdev] gcc 4.8.x dragonegg support
On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote:
> On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote:
> > Duncan,
> > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn
> > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic
> > to work around without some
2012 Dec 10
0
[LLVMdev] pb05 benchmarks for llvm/dragonegg 3.2
Hi Jack, thanks for these numbers.
> With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html,
> the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what
> were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05)
>
2011 Oct 08
4
[LLVMdev] dragonegg svn benchmarks
The Polyhedron 2005 benchmark results for dragonegg svn at r141492
using FSF gcc 4.6.2svn measured on x86_64-apple-darwin11 are listed below.
The benchmarks used the optimizaton flags...
-msse4 -ffast-math -funroll-loops -O3
in all cases. The use of -fplugin-arg-dragonegg-enable-gcc-optzns to allow
for autovectorization from the FSF gcc front-end only produces a single run-time
regression,
2013 May 23
0
[LLVMdev] Polyhedron 2005 results for dragonegg 3.3svn
Duncan,
With r182593, the dragonegg 3.3 branch now completely passes the Polyhedron 2005 benchmarks
using the FSF gcc 4.8.1svn compiler. Thanks.
Jack
Tested on x86_apple-darwin12
Compile Flags: -ffast-math -funroll-loops -O3
de-gfortran47: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -specs=/sw/lib/gcc4.7/lib/integrated-as.specs
de-gfortran48:
2013 May 23
1
[LLVMdev] Polyhedron 2005 results for dragonegg 3.3svn
On Thu, May 23, 2013 at 03:40:00PM +0200, Duncan Sands wrote:
> Hi Jack,
>
> On 23/05/13 15:37, Jack Howarth wrote:
>> Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current
>> FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is
2011 Sep 06
1
[LLVMdev] major dragonegg improvement
Try -mllvm -disable-unroll-scev if you're curious.
There can be some luck involved. If you have the bitcode for the important function, I may be able to convert it into a test case to avoid regressing. I usually grab the unoptimized bitcode as follows: -emit-llvm -mllvm -disable-llvm-optzns -o module.bc
-Andy
On Sep 6, 2011, at 12:03 PM, Owen Anderson wrote:
> Seems very likely to be
2013 May 23
4
[LLVMdev] Polyhedron 2005 results for dragonegg 3.3svn
Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current
FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980
which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this
2011 Sep 06
0
[LLVMdev] major dragonegg improvement
Seems very likely to be related to Andy's SCEV-unroll-loops changes.
--Owen
On Sep 6, 2011, at 11:56 AM, Jack Howarth wrote:
> I'm not certain yet which commit in the last couple of days caused this,
> but the current llvm/dragonegg svn shows a major improvement in the runtime
> of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the
> dragonegg plugin
2010 Apr 09
1
[LLVMdev] dragonegg FSF gcc merge?
On Apr 9, 2010, at 10:11 AM, Jeffrey Yasskin wrote:
>>
>> Duncan,
>> I'll broach the topic on gcc at gcc.gnu.org and see what the
>> responses are. Why can't dragon-egg live in both places and
>> be re-merged regularly?
>
> Re-merging it regularly sounds like it would require extra work beyond
> what Duncan's already doing to maintain it.