similar to: [LLVMdev] Question about the old C back-end

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

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

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,

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

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

*> 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 ".s file" at the end. -Chris I see that Chris made the above suggestion a while ago. Are

errata: I am on 3.6 full stop. I *thought* there was a 3.7 available, based on the title of http://llvm.org/docs/ ("LLVM 3.7 documentation"). I suppose the docs are ahead of the release schedule? On Sun, Mar 8, 2015 at 9:44 AM Mircea Trofin <mtrofin at google.com> wrote: > Sorry, that phase is part of the PNaCl toolchain. This would be LLVM 3.6, > would your comments still

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

Hi, I was looking into the semantics of GEP inbounds and some BasicAA rules and I'm wondering if it's valid in LLVM IR to allocate more than half of the address space with a global variable or an alloca. If that's a scenario want to consider, then we have problems :) Consider this C code (32 bits): #include <string.h> char obj[0x80000008]; char f() { char *p = obj +

The docs say "[byval] indicates that the pointer parameter should really be passed by value to the function. The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee." I am not sure what this means though - when I generate code from the LLVM assembly, do I need to do anything with byval?

On Dec 6, 2011, at 4:13 PM, Devang Patel wrote: > Hi Josh, > > On Dec 4, 2011, at 9:33 PM, Josh Matthews wrote: > >> I'm working on generating debug information for Rust, and I'm >> currently stumped on how to generate DWARF output via LLVM that will >> correctly represent this (eg. when exiting from foo2(), I'd like to >> see "Value returns

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, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

On 07/24/2015 03:42 AM, Benjamin Kramer wrote: >> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: >> >> It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing

Many thanks for the pointer! I missed that bug report since the title was about GVN. If there's interest in supporting this feature I can help since we've formalized most of BasicAA. I can easily verify if proposed changes are correct. (I'll release the code soon). Nuno Quoting Björn Pettersson A <bjorn.a.pettersson at ericsson.com>: > Hi Nuno. > I can't

Hi, I’ve come back and updated my llvm toolset with modern code (my branch was about 1-2 years old) and now the llvm IR files produced by my front end no longer compile with llc. Here is a sample of llvm ir produced by my front end (it’s a standard version 3.1 build of swift from the swift.org open source website). ; ModuleID = 'main.ll' source_filename = "main.ll" target

Unfortunately this is what I'm already doing, and it's not working. I drew inspiration from a disassembly of a program that showed that struct foo { int a; float b; char buf[80]; } struct foo get_foo(void) { foo f = { 5, 2.5 }; return f; } would turn into define void @get_foo(%struct.foo* sret %agg.result) nounwind ssp { ... call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8*

On 27.08.2012 22:56, Roel Jordans wrote: > > Anyway, that brings to my final question: Which features are > critical/important/wanted/unwanted for a C back-end? > I'd like it to be easy to configure (e.g. to tell which size int is assumed to have). I'd prefer the resulting code to not rely on implementation-defined behaviour (e.g. not make any assumptions about the size of

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.