search for: retargett

...年9月15日(星期二) 上午7:34 To: "llvmdev"<llvmdev at cs.uiuc.edu>; Subject: [LLVMdev] Dear LLVM, Dear LLVM, Now, I have to design special complier for my own multicore microprocessor with cusomized instruction-set and optimized architecture. After have read a lot of papers about LLVM--a retargettable compiler framework, I still can't catch it clearly how to make LLVM support my target. Would you please give me some necessary instructions or advice? Thanks! Robinson Xu ECE of Gatech _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu...

Dear LLVM, Now, I have to design special complier for my own multicore microprocessor with cusomized instruction-set and optimized architecture. After have read a lot of papers about LLVM--a retargettable compiler framework, I still can't catch it clearly how to make LLVM support my target. Would you please give me some necessary instructions or advice? Thanks! Robinson Xu ECE of Gatech

...gister allocator has some sparc specific details built into it (also, the TargetRegInfo interface assumes a graph coloring register allocator, so it is not a generic interface). We are slowly working on bringing the two representations together so that we can have a unified backend which is easily retargettable, but this is still a ways off. In the X86 code generator, Alkis has been working on tuning up his new linear scan register allocator, so that will improve things. He too is interested in graph coloring allocators... maybe he can say more. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondo...

Hi all, I was looking at the register allocator code and had a question about that: CodeGen/RegAlloc/PhysRegAlloc.cpp implements a graph coloring register allocator for the Sparc back end. It requests target machine register information via a call to getRegInfo() which returns a class TargetRegInfo containing the required information. For the x86 target machine, this interface has not been

No, its up to them which backend they want to use. Sounds like they think that GCC is super quick compared to LLVM. Looks like another fud fart out of google to me. 2009/11/12 Jon McLachlan <mclachlan at apple.com>: > Any plans to make LLVM work with Google's new language, Go? > >

...'s definitely slower than a non-optimizing compiler. They then later implemented an optimizing implementation, which they based on GCC because they had a team member (Ian) who is a GCC expert. On the positive side, Ian seemed very positive and even encouraging that his GCCGo frontend might be retargettable from GCC to LLVM, so I wouldn't rule it out as a possibility if some interested community members stepped up to do it. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/556dafb6/attachmen...

Any plans to make LLVM work with Google's new language, Go? http://www.technewsworld.com/story/Go-Go-Google-Programming-Language-68622.html?wlc=1257974768&wlc=1258041607&wlc=1258047741

I received a sample IP/Speakerphone from my friends in China today. Asterisk setup was fairly uncomplicated and I had it running as an extension on my server within a few minutes. Sounds quality of both the receiver and the speakerphone are fine (wife's opinion). Are there any tests I should run with this phone? Following are the specs: - Single line appearance - Alpha display, 2x16 chars -