similar to: [LLVMdev] Does current LLVM target-independent code generator supports my strange chip?

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

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

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

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

On Nov 22, 2008, at 7:48 AM, Wei wrote: > 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. See ValueTypes.h and ValueTypes.cpp. Also this example: @str = internal constant [4 x i8] c"%d\0A\00" define void @foo2(i24 %a, i24 %b) nounwind

Let me clarify - I haven't used LLVM for GLSL - I'm also relatively new to LLVM targeting a modern GPU. My GLSL work was back in the timeframe of AMD's R300/R400 series, which was 4 years ago. On Nov 24, 2008, at 10:25 AM, Wei wrote: >> The machines I worked with didn't support any integer ops, but GLSL >> let us get by with "emulated" 16 bit integers

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++++++----- arch/x86/crypto/aesni-intel_asm.S

Hello guys, I am experiencing a strange behaviour with HTB. Here is my situation: Test PC -------- internet ------------- ISP ----- fiber connection --------- (eht2) RT1 (eth1) --------- wireless connection ------------ (eth4) RT2 (eth0) -------- users RT1 - Slackware router RT2 - Slackware router Delay between Test PC and ISP is approx 450 ms. I have the following shapers

hello, i want to know if there is any method to route traffic based on the load of a link. imagine the following scenario: +----------+ +------+ +------+ +----------+ | subnet 1 |#####| rt 1 |--------| rt 2 |#####| subnet 2 | +----------+ +------+ +------+ +----------+ \ / \ +------+ /

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

Hello, My ultimate goal is a repeated measures (mixed model) ANOVA, however, my present question is about how to reorganize my data into the format that the ANOVA commands expect. In particular, how to collapse across trials. (I am using the tutorial at [http://personality-project.org/r/r.anova.html] for the mixed model ANOVA) The data I am using looks like this. A subject sees 10 trials per

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

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - 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