similar to: [LLVMdev] defining types structurally equivalent to a recursive type

On Thu, Nov 11, 2010 at 8:28 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Hi all, > > http://www.llvm.org/docs/ProgrammersManual.html#BuildRecType suggests > us to define recursive types via opaque and refine. Since LLVM has > structural types, %rt = type { %rt* } and %rt1 = type { %rt* } should > be same structurally. I tested the following code, > > %rt =

>> >> I think I may have found an exception to this -- the API seems to >> require me to have all the fields for a struct ready before I >> construct the struct. I don't have the ability to make a struct >> type, use it to declare some variables, and still contribute fields >> to it during the rest of the compilation. >> >> Is there a

On Jun 12, 2008, at 13:25, Hendrik Boom wrote: > So it appears that types are processed for identity the moment they > are made during parse tree construction? Yes. > This means that a type has to be completely known on creation. Yes. > Presumably there's some mechanism tor a type that isn't completely > known yet -- or is thet avoided by having a type

Hello, Can I define a named type ? %rt = {%rt} llvm-as can parse this definition without errors. JIT executes '%0 = alloca %rt' as allocating a memory with size 0. Because the llvm::TargetData::getTypeAllocSize accually returns 0 in this case. The function that calculates %rt's size is by the TargetData::getStructLayout, which calculates the a layout of %rt. It can only returns 0

On Thu, Nov 11, 2010 at 12:11 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 11, 2010, at 8:45 AM, Jianzhou Zhao wrote: > >> Hello, >> >> Can I define a named type ?   %rt = {%rt} >> llvm-as can parse this definition without errors. >> >> JIT executes '%0 = alloca %rt' as allocating a memory with size 0. >> Because the

On Nov 11, 2010, at 8:45 AM, Jianzhou Zhao wrote: > Hello, > > Can I define a named type ? %rt = {%rt} > llvm-as can parse this definition without errors. > > JIT executes '%0 = alloca %rt' as allocating a memory with size 0. > Because the llvm::TargetData::getTypeAllocSize accually returns 0 in > this case. The function that calculates %rt's size is by the

I have a very strange and complicate H/W platform. It has many registers in one format. The register format is: ------------------------------ ---------------------------------------------------------------------------------------- | 24-bit | 24-bit | 24-bit | 24-bit |

Why not model each channel as a separate physical register? Evan On Nov 17, 2008, at 6:36 AM, Wei wrote: > I have a very strange and complicate H/W platform. > It has many registers in one format. > The register format is: > > ------------------------------ > ---------------------------------------------------------------------------------------- > | 24-bit

Hey All I''m Using Xen 3.0.3-105 on CentOS 5.5. It Has to Nics: eth0 - Internet eth1 - Internal Lan ( where Dhcp , DNs , Cobbler - Kick Start Server Resides ) I''ve Set xend-config.xsp to create xenbr1 on eth1 and it looks well So Guest May Get Access TO ALl Resources via the Bridge. brctl show bridge name bridge id STP enabled interfaces xenbr1

24 bit is not unusual in the DSP world. I suppose int == 24 bit integer for some of these chips? There isn't a i24 simple type. However, you can create an extended integer type. See getExtendedIntegerVT. It's almost guaranteed you will have to change a chunk of target independent codegen to support the use of an extended type though. Evan On Nov 20, 2008, at 4:46 AM, Wei wrote:

Because each channel contains 24-bit, so.. what is the llvm::SimpleValueType I should use for each channel? the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32, f64, f80, none of them are fit one channel (24-bit). I think I can use i32 or f32 to represent each 24-bit channel, if the runtime result of some machine instructions exceeds 23-bit (1 bit is for sign), then it is an

This is similar to ATI's R300/R420 pixel shaders. I'm familiar with this hardware, but not really an LLVM expert (working on a code generator myself, but learning as I go). Do you have 24-bit integer operations, or just floating point? What about load/store? Are you looking to run large C programs with complex data structures, or just comparatively simple math functions (i.e. a

Do you mean MVT::getIntegerVT? Because I can not find getExtendedIntegerVT in the llvm source codes. I am excited seeing this function, however I have the following more questions. 1) You mention I will have to change not small amount of target indenpendent codegen codes to support this extended type. Are there any document to describe how to do such kind modification? I see there is a

Hi, I've followed the instructions on constructing recursive types ( http://llvm.org/docs/ProgrammersManual.html#BuildRecType) and I can succesfully create simple recursive types using the C bindings (e.g. struct Test { struct Test *t };). I want to generalize this to get type information from my language into generated LLVM code. My language allows arbitrary forward type declarations that I

I have 24-bit integer operations as well as 24-bit floating point (s7.16) operations. The H/W supports load/store instructions, however, they does suggest us not to use these load/store instructions besides debugging purpose. That is to say, you can imagine we don't have load/store instructions, we don't have memory, we just have registers. I will run OpenGL shading laugnage programs on

Hi Gordon, Thanks for your comments. > > Constant.string(value, dont_null_terminate) -- value is a string > > Constant.struct(consts, packed) -- a struct, consts is a list of > > other constants, packed is boolean > > I did this in Ocaml initially, but found the boolean constants pretty > confusing to read in code. I kept asking "What's that random true

On my debian woody (kernel 2.4.31) the tcpdump doesn''t work with imq0 devices. If I try to tcpdump imq devices there is no packet seen: [...] rt1:~# tcpdump -n -i imq0 Warning: arptype 65535 not supported by libpcap - falling back to cooked socket tcpdump: WARNING: imq0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on

On Nov 22, 2008, at 11:03 AM, Wei wrote: > I have 24-bit integer operations as well as 24-bit floating point > (s7.16) operations. > > The H/W supports load/store instructions, however, they does suggest > us not to use these load/store instructions besides debugging purpose. > That is to say, you can imagine we don't have load/store instructions, > we don't have

> The machines I worked with didn't support any integer ops, but GLSL > let us get by with "emulated" 16 bit integers (storing and operating > on them as floating point; divides required truncation after the op - > that sort of thing). Although my platform indeed supports integer operations, however, it only supports integer +,-,*, not /. The document says if I need to

> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > -Chris So I succeeded in using a "PATypeHolder" for the "opaque" type, define a Type* with PointerType::getUnqual, prepare