similar to: [LLVMdev] guidance on backend writing; canonical example?

On 13 March 2013 01:50, Jason E. Aten <j.e.aten at gmail.com> wrote: >> Chris Lattner, Mon Nov 15 12:06:18 CST 2010, wrote: >> >> If anyone was really interested in this, I'd strongly suggest a complete >> rewrite of the C backend: make use the existing target independent code >> generator code (for legalization etc) and >> then just put out a weird

Hello all, As some of you may remember, I am trying to get the C back-end back in working condition. I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the current trunk. === Question 1: new design feedback === I am currently looking into moving the CBE to run after the initial lowering and type legalization phases so that

Hello all, When going through the internals of the old C back-end, I see that the CBE encapsulates arrays into a struct. The source code has the following comment to explain this behaviour. // Arrays are wrapped in structs to allow them to have normal // value semantics (avoiding the array "decay"). For example, the CBE translates: @a = common global [10 x i32]

Hi Duncan, On 11/10/12 15:47, Duncan Sands wrote: > Hi Roel, > >> When going through the internals of the old C back-end, I see that the CBE >> encapsulates arrays into a struct. The source code has the following comment to >> explain this behaviour. >> >> // Arrays are wrapped in structs to allow them to have normal >> // value semantics

Hi Arnold, On 06/12/12 08:50, 陳韋任 (Wei-Ren Chen) wrote: > On Thu, Dec 06, 2012 at 10:05:03AM +0800, Mingliang LIU wrote: >> Hi Arnold, >> >> Thank you. I googled but missed the release notes. >> >> Regards. > > Someone else out there tried to bring cbe back. You can search the ML > archieve and reach them out. > That would be me. > Regards,

Hi Roel, > When going through the internals of the old C back-end, I see that the CBE > encapsulates arrays into a struct. The source code has the following comment to > explain this behaviour. > > // Arrays are wrapped in structs to allow them to have normal > // value semantics (avoiding the array "decay"). > > For example, the CBE translates: >

For those wondering about the C backend, a patch(set) to current trunk is available but too large to send through the LLVM mailinglist. I can send the patch(es) directly if people are interested. Cheers, Roel On 17/11/12 03:48, David Claughton wrote: > Hi Roel, > > On 13/09/12 11:02, Roel Jordans wrote: >> >> For those that are interested, I can provide a patch to the

Hi Arnold, Thank you. I googled but missed the release notes. Regards. On Thu, Dec 6, 2012 at 12:13 AM, Arnold Schwaighofer < arnold.schwaighofer at gmail.com> wrote: > The C Backend was remove in 3.1 > (http://llvm.org/releases/3.1/docs/ReleaseNotes.html): > > "Major Changes and Removed Features > ... > The C backend has been removed. It had numerous problems,

On Wed, Nov 21, 2012 at 1:53 AM, Roel Jordans <r.jordans at tue.nl> wrote: > For those wondering about the C backend, a patch(set) to current trunk is > available but too large to send through the LLVM mailinglist. I can send > the patch(es) directly if people are interested. > That *is* interesting. I suppose you could use any of the number of free file/snippet/paste upload

On Thu, Dec 06, 2012 at 10:05:03AM +0800, Mingliang LIU wrote: > Hi Arnold, > > Thank you. I googled but missed the release notes. > > Regards. Someone else out there tried to bring cbe back. You can search the ML archieve and reach them out. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

On 10/10/12 18:57, Nadav Rotem wrote: > Hi Roel! > > > On Oct 10, 2012, at 5:29 AM, Roel Jordans <r.jordans at tue.nl> wrote: > >> Hello all, >> >> As some of you may remember, I am trying to get the C back-end back in working condition. I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the

Hi All, 2 of my summer interns (Aimee Dipietro and Greg Simpson) used their time over the summer to resurrect the LLVM C Backend: https://github.com/draperlaboratory/llvm-cbe Improvements include recovery of simple for/while loops (instead of goto), better variable naming, inline asm support, and making it work on a more recent version of llvm. I believe they used the repository here as a

http://llvm.org/docs/CodeGenerator.html#feat_inlineasm_x86 The following issue is resolved, so the x86 inline asm should be fine now:) http://llvm.org/bugs/show_bug.cgi?id=862 -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello all, I am in need for a working C back-end for LLVM for my current research. I know that the previous incarnation of this back-end has been kicked out of the tree since the 3.1 release and I have gone through the archives to restore it to it's previous 'glory'. So far, I have restored most of the previous version (excluding some of the parts that needed changes outside of

Hello all, I am currently working with LLVM and make use of the debug output from llc. The SelectionDAG dumping features are especially interesting to me since I am looking for operation patterns that allow me to decide which custom instructions can be added to a processor in order to improve the performance. Providing a -view-dag-combine1-dags option (and its friends) to llc show the

Senhores, bom dia! Tem como instalar o Samba 4 com o antivirus ClamAV? Achei v?rios artigos, mas n?o consegui fazer funcionar o ClamAV. Desde, j? agrade?o a aten??o de todos. Atenciosamente, Marcio Fiorette

I move my notebook around my office. Sometimes I am using the internal pointers, sometimes a USB mouse, and sometimes a USB keyboard/mouse adapter that is plugged into a kvm (actually two of them). With one of these USB k/m adapters, when I plug in, the system fails to recognize the mouse (but no problem with the keyboard). The 2 adapters are the same brand/model (Aten), but the KVMs are

Duncan Sands <baldrick at free.fr> writes: >> There's a big reason to keep it. It's a godsend when trying to bugpoint >> something where no working llc is available. I've used it quite a lot >> during AVX development, for example. It's useful for developing any >> new target. > > an alternative is to make the interpreter more powerful and

A sublte question about Dragonegg: is Dragonegg usable for Just-in-time compiling as well as ahead-of-time compilation? If not, how hard would it be to enable JIT using dragonegg? Say one wanted to use the gnu fortran-2008 front end, and to jit up some fortran code. How difficult would it be to adapt it? Thank you. Jason -- Jason E. Aten, Ph.D. -------------- next part -------------- An HTML

On Nov 15, 2010, at 9:22 AM, John Criswell wrote: > On 11/15/10 11:17 AM, David A. Greene wrote: >> Duncan Sands<baldrick at free.fr> writes: >> >>>> There's a big reason to keep it. It's a godsend when trying to bugpoint >>>> something where no working llc is available. I've used it quite a lot >>>> during AVX development,