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

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Removal of IA-64 target"

2009 Jul 16
0
[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
2009 Jul 17
2
[LLVMdev] Removal of IA-64 target
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
2009 Jul 17
2
[LLVMdev] Removal of IA-64 target
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 >>
2009 Jul 17
0
[LLVMdev] Removal of IA-64 target
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
2009 Jul 17
0
[LLVMdev] Removal of IA-64 target
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...
2008 May 20
2
[LLVMdev] [ia64] Assertion failed: (!OpInfo.AssignedRegs.Regs.empty() && "Couldn't allocate input reg!")
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
2008 May 20
1
[LLVMdev] [ia64] Assertion failed: (!OpInfo.AssignedRegs.Regs.empty() && "Couldn't allocate input reg!")
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
2008 May 20
0
[LLVMdev] [ia64] Assertion failed: (!OpInfo.AssignedRegs.Regs.empty() && "Couldn't allocate input reg!")
[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 =
2009 Jul 17
1
[LLVMdev] Removal of IA-64 target
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
2008 May 25
1
[LLVMdev] A quick update on FreeBSD support
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
2008 May 24
5
[LLVMdev] A quick update on FreeBSD support
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
2008 May 24
2
[LLVMdev] A quick update on FreeBSD support
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
2008 May 25
3
[LLVMdev] A quick update on FreeBSD support
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?
2008 May 26
0
[LLVMdev] A quick update on FreeBSD support
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
2008 May 24
0
[LLVMdev] A quick update on FreeBSD support
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++
2003 May 21
6
5.0-RELEASE --> cannot build any Mozilla Version
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
2008 May 28
0
[LLVMdev] A quick update on FreeBSD support
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!
2008 May 05
2
PCI serial card works on 6.2 but not on 6.3
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
2008 May 26
2
[LLVMdev] use after free [was: A quick update on FreeBSD support]
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. > >
2008 Jun 17
1
[LLVMdev] PowerPC instruction cache invalidation
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!