similar to: [LLVMdev] 16 bit floats

----- Original Message ----- From: Villmow, Micah To: LLVM Developers Mailing List Sent: Friday, February 06, 2009 5:47 AM Subject: [LLVMdev] 16 bit floats I need to support 16 bit floats for some operations, outside of datatypes.td and the constants class, is there anything else I will need to modify to add f16 support? probably also code generation (can't give specifics, no

On Feb 5, 2009, at 12:51 PM, BGB wrote: > > ----- Original Message ----- > From: Villmow, Micah > To: LLVM Developers Mailing List > Sent: Friday, February 06, 2009 5:47 AM > Subject: [LLVMdev] 16 bit floats > > I need to support 16 bit floats for some operations, outside of > datatypes.td and the constants class, is there anything else I will > need to modify to

BGB/Chris, I need to do a similar where I convert the 16bit floats to 32bit floats on memory operations for both scalar and vector formats. So can these operations be implemented without adding 16 bit float support natively to LLVM? If so, how? ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent:

On Mon, Sep 29, 2008 at 8:11 PM, Mon Ping Wang <wangmp at apple.com> wrote: > The problem with generating insert and extracts is that we can generate poor > code > %tmp16 = extractelement <4 x float> %f4b, i32 0 > %f8a = insertelement <8 x float> %f8a, float %tmp16, i32 0 > %tmp18 = extractelement <4 x float> %f4b, i32 1 > %f8c

Hi, The current definition of shuffle vector is <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> ; yields <n x <ty>> The first two operands of a 'shufflevector' instruction are vectors with types that match each other and types that match the result of the instruction. The third

On Thu, Feb 5, 2009 at 1:34 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I need to do a similar where I convert the 16bit floats to 32bit floats on > memory operations for both scalar and vector formats. So can these > operations be implemented without adding 16 bit float support natively to > LLVM? If so, how? In this case, you only really need two currently

I've patched valuetypes.td/h to add data types that my backend needs to support. There seems to be a lot of assumptions made in other spots of the code that limit the number of data types to 32. I need to add a few more types, but once I go over this limit llvm starts acting wonky. I found all the items that are hard coded to 32 and a section that isn't, but I cannot figure out how to

Currently with my understanding of using callingconv.td I still need to lower three functions, FORMAL_ARGUMENTS, CALL, and RET. Is there any known way to have LLVM automagically generate code from tablegen without having to custom lower these functions? The reasoning for this is that all registers are virtual in my backend and I have specified for llvm to use it's generic dynamic stack

Hi Guys, I am trying to promote half to float for my intrinsic math operations, following class and pattern are defined. " class S_HF__HF< string asmstr> : Intrinsic <[llvm_float_ty ], [llvm_float_ty ], [IntrNoMem], !strconcat(asmstr, "_f16")>; def :Pat<( f16 (int_my_math_f16 f16:$src)), (F2Hsr (FEXTsr f16:$src) )>; “ where FEXTsr is

It seems that LLVM is converting all the 16 bit ints into 32 bit ints. Is there a way I can tell LLVM that 16 bit ints are valid and legal and not to do any conversions on them? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part

How do I match against this instruction? 01ABDA58: i64,ch = load 01ABD948, 01ABD8C0, 01AB1350 <null:0> This is the first time I've seen NULL in the memory operand location. Any idea on how this could be mapped with tablegen correctly? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale,

I'm hitting an issue where legalizeOp is overflowing the stack. Are there any recommended ways of getting around this? The bitcode that causes this issue is attached. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An

Hello, Code: int f1(int a, int b) { return sqrt(a) > sqrt(b); } int f2(int a, int b) { return a > b; } Possibly, under -ffast-math (to ignore NaNs), f1 could be transformed to f2 variant. Also a transformation could support sin and tan, and reverse comparison for cos. Suggestions? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I've recently run into an unknown bit in Tesla shaders, and was hoping you could shed some light on it. I believe they're related to clamping of some sort. Here are 2 examples (from diff shaders): a0000401 cc054780 cvt rpi f32 $r0 f32 $r2 [unknown: 00000000 00010000] a000060d 8c014780 cvt rni s32 $r3 f32 $r3 [unknown: 00000000 00010000] [This is intel-style syntax, cvt =

Hi, I am working on DSP module of Ne10. I see there are fixed-point and floating-point FFT inside Opus. Is fixed-point FFT only a fall back for CPU without VFP? On ARMv7-A and ARMv8-A, benchmark result shows that fixed-point (int32) and floating-point (float32) FFT have similar performance. I guess fixed-point version is not often used on these platforms. Is it worth the effort to NEON-optimize

Dear R_Help: The following gives me a matrix with integer values. z= matrix(rep(10:1, each= 10), ncol= 10, byrow=TRUE)> str(z)?int [1:10, 1:10] 10 9 8 7 6 5 4 3 2 1 ... How do I specify that I want Float32 values instead. Thanks,Chris

Eli, This is similar to what I was originally thinking, but I also need to support i16 data type and conversions between it and floating point values. So would there be a way for me to distinguish between a half and a short? For example, I have the short a = load_from_memory(short_ptr, index); and half a = load_from_memory(half_ptr, index); if I force it to use i16 wouldn't the function be

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow

Are you marking i16 a legal type? In XXISelLowering.cpp, you should assign it a register class. e.g. addRegisterClass(MVT::i16, XX::i16RegisterClass) Evan On Feb 2, 2009, at 12:19 PM, Villmow, Micah wrote: > It seems that LLVM is converting all the 16 bit ints into 32 bit > ints. Is there a way I can tell LLVM that 16 bit ints are valid and > legal and not to do any conversions

It depends on how your target models its addressing mode. Targets with complex addressing modes usually isel addresses with custom code. Evan On Mar 6, 2009, at 4:05 PM, Villmow, Micah wrote: > How do I match against this instruction? > 01ABDA58: i64,ch = load 01ABD948, 01ABD8C0, 01AB1350 <null:0> > > > This is the first time I’ve seen NULL in the memory operand >