similar to: [LLVMdev] named types with self-references

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

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

I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this difference in alignment and

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 |

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

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 = type { %rt* } %rt1 = type { %rt* } define i32 @main() nounwind { entry: %0 = alloca %rt ;

It sounds like your DataLayout may not match clang's for x86_64-linux. What does it say about the alignment of i64? On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` > is returning `12`. `getStructLayout` also gives an `4` offset for the > second

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

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 =

Dear Group, I have been successful in setting up the Agents, queues and getting agents to log in. Is there a way that I could configure the system so that the agent is called back. i.e. the agent logs into the system, a call is destined for them and their phone rings. If some one has this setup I would be very interested in hearing from them. Warm Regards and Thanks --------------- Shad

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:

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

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

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struct test1 { short f0 : 10; char f1 : 5; long f2 : 1;

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to