similar to: [LLVMdev] !!! 3.2 Release RC2 deadline November 29th

Pawel, Is it still not too late to merge these patches? r168471 r168460 r168458 r168456 r168455 r168453 r168450 r168448 These patches fix a bug in mips backend's GOT implementation and add support for big-GOT relocations. Thank you. On Tue, Nov 27, 2012 at 7:35 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > Hello, > > Just a quick reminder that the November 29th

Akira, > Pawel, > > Is it still not too late to merge these patches? > > r168471 > r168460 > r168458 > r168456 > r168455 > r168453 > r168450 > r168448 > > These patches fix a bug in mips backend's GOT implementation and add > support for big-GOT relocations. That's quite a list of patches! To get them into the 3.2 release you would first

On Nov 27, 2012, at 7:35 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > Hello, > > Just a quick reminder that the November 29th (10p.m. PST) is the > end of Phase 1 testing and Release Candidate 2 (RC2) deadline. > After RC2 deadline, LLVM-Clang 3.2 release will be considered feature > complete and no new functionality can be added. > > With 2 days left

We have 10 dragonegg builders in the buildbot. 8 of them bootstrap (all are green) but they build dragonegg with dragonegg. 2 run test-suit. Building clang with the dragonegg surely is a good test, but is this a release requirement? If it is, we need another builder. -Galina On Wed, Nov 28, 2012 at 9:02 AM, Tanya Lattner <lattner at apple.com> wrote: >> 14429 - Dragonegg fails to

On 28 Nov 2012, at 17:02, Tanya Lattner wrote: >> 14116 - Inliner incorrectly combines cleanup and catch landing pads > > I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month. This bug means that we can't compile at anything over -O1, or we get code that does the wrong thing (e.g. terminate instead of catching an

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

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. > > >

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

On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote: > Attached is a prototype patch that uses CCState to lower RET nodes in > the ARM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, so it should already be handled. > > > def

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).

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>,

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On Nov 28, 2012, at 9:30 AM, David Chisnall <dc552 at cam.ac.uk> wrote: > On 28 Nov 2012, at 17:02, Tanya Lattner wrote: > >>> 14116 - Inliner incorrectly combines cleanup and catch landing pads >> >> I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month. > > This bug means that we can't

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

On Tue, Apr 03, 2012 at 08:33:33AM -0500, Hal Finkel wrote: > 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 Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it bespoke C++ > code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :)

How/where are function prologs and epilogs generated, is it bespoke C++ code or TableGen generated ? If someone could point me in the right direction please. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090409/fb3336e4/attachment.html>

How about vector parameters? define internal fastcc <4 x float> @add(<4 x float> %a.val, <4 x float> %b.val) nounwind { entry: %tmp4 = fadd <4 x float> %a.val, %b.val ret <4 x float> %tmp4 } a and b are flattened by SelectionDAGISel::LowerArguments(const BasicBlock *LLVMBB) before letting the target handle it. SDValue NewRoot =

I'm having some issues getting app_voicemail_imapstorage to talk to my IMAP server. From imapstorage.txt, I've got the voicemail.conf configured properly, but if I leave a voicemail for extension 9999, I see no indication that the module is trying to reach the IMAP server. What am I missing? # voicemail.conf [general] imapserver=172.16.17.2 [default] 9999 =>