similar to: [LLVMdev] Removal of IA-64 target

On Jul 16, 2009, at 1:38 PM, Dan Gohman wrote: > Hello, > > LLVM's IA-64 target has not been maintained for a few years, and it is > currently unable to compile many simple testcases. I'm planning to > remove it from the tree soon, unless someone objects. Ouch. The FreeBSD project is putting serious effort in getting the OS to compile with LLVM with a future possibility

On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > > BTW: I don't run Linux at all, so no Linux/ia64 support. > I can see how that could be a problem for people. > > Anyway: my case is a weak one and I would understand if the > target get axed without considering my email/request... Hi Marcel, There are two levels of problems with the IA64 backend. On the first

On Jul 16, 2009, at 9:49 PM, Marcel Moolenaar wrote: >> For us to keep IA64 around (and for it to be minimally useful for >> your >> work!), I think that the backend should pass most of the simple >> programs in MultiSource/Benchmarks for example. It does *not* need >> to >> produce amazingly fast code, but the code needs to work. I don't >>

On Jul 16, 2009, at 10:22 PM, Chris Lattner wrote: > >> However, I do not want to go anywhere near trying to achieve optimal >> code generation right now. Getting functional completeness is as high >> as I dare to shoot. I presume that it'll be daunting enough. > > It depends a lot on your background, but yes it is a substantial > amount of work. Low-level

On Jul 16, 2009, at 5:51 PM, Chris Lattner wrote: > > On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > >> >> BTW: I don't run Linux at all, so no Linux/ia64 support. >> I can see how that could be a problem for people. >> >> Anyway: my case is a weak one and I would understand if the >> target get axed without considering my email/request...

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

On Tue, 20 May 2008, Marcel Moolenaar wrote: > On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: >> The following IR is causing the assert: The issue here is that the IA64 backend doesn't have inline asm support yet. This should be pretty easy to add. Take a look at the X86 version: X86TargetLowering::getRegForInlineAsmConstraint it just maps "r" onto the GPR

[correction] On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: > All, > > The following IR is causing the assert: > > \begin{ll} > ; ModuleID = 'x.bc' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- > f80:128:128" > target triple =

On Jul 17, 2009, at 9:53 AM, Marcel Moolenaar wrote: >> >> At this point, I think we should remove the Itanium backend from >> mainline. I would be thrilled if you would take it and fix it up and >> get it working out of tree. If you get it working on significant >> programs (regardless of the performance of those programs) we'd >> definitely accept it

Hello, Marcel First of all, thank for your great job for trying llvm-gcc on FreeBSD! Some quick notes below: > o Adding support for inline assembly for ia64 (already started) and > improving ia64 in general. This is longer term work... Please note, that IA64 didn't have active maintainer for some time (maybe year or even two), so it can be heavily broken for some things. I bet

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > >> On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> >>> Let us know if you would like extra eyes on the two PPC failures. >>> Many >>> of us have a lot of experience with C++. :-) Do you know where these >>> allocations are?

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

Hi, I am running FreeBSD 5.0-RELEASE-p7 and cannot build any Mozilla version from ports. The build exits for all versions at the same point. A source file called jsdtoa.c. Thanks.. Here is my error report: ******************************************************************************* cc -o jsdtoa.o -c -DOSTYPE=\"FreeBSD5\" -DOSARCH=\"FreeBSD\" -DEXPORT_JS_API

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked flawlessly on 6.2 with puc(4) driver. >From dmesg: pci1: <simple comms, UART> at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00

On May 26, 2008, at 1:25 AM, Bill Wendling wrote: > On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: >> On May 25, 2008, at 12:58 AM, Bill Wendling wrote: >> >>> Could you try this (massively hacky) patch out to see if it fixes >>> your >>> problem? >>> >>> >> Alas, it didn't fix the problem: >> > Crumbs. > >

Chris Lattner wrote: > On Mon, 16 Jun 2008, Gary Benson wrote: > > When you genetate code on PowerPC you need to explicitly > > invalidate the instruction cache to force the processor to reread > > it. In LLVM there is code to do this for function stubs on > > Macintosh, but not for other platforms and not for JITted code > > generally. > > Applied, thanks!