search for: sign_bit

...ssible to be more generic? > sext_from type where type can be any type? The value of the > attribute would somehow tells us the type before extension? Why not the values codegen is actually looking for? Say, these attributes: known_bits(mask, bits) ; Partially known values. sign_bits(num) ; Number of leading sign extended bits. Example: ; unsigned char f(bool, signed char) define i32 known_bits(0xFFFFFF00, 0) @f(i32 known_bits(0xFFFFFFFE, 0) %b, i32 sign_bits(25) %c) If the attribute values were encoded as constants, these could...

On May 29, 2008, at 10:30 AM, Alireza.Moshtaghi at microchip.com wrote: > > > 4) There will be 4 new function attributes: > sign_ext_from_i8, sign_ext_from_i16 > zero_ext_from_i8, zero_ext_from_i16 > These attributes will be placed on the function CALL node by > front-end > to inform the backend about such promotions and enable optimization > of > return

...>> sext_from type where type can be any type? The value of the >> attribute would somehow tells us the type before extension? > > Why not the values codegen is actually looking for? Say, these > attributes: > > known_bits(mask, bits) ; Partially known values. > sign_bits(num) ; Number of leading sign extended bits. Yes, this would be much nicer. The only issue is that attributes are currently a bitfield, so they can't be parameterized. I'd love to see this get fixed. Another issue with attributes is that they can't be applied to multip...

...re are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeting has different performance constraint...

...re are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. > I've tried a custom lowering function that lowers it to dst = sub 0, src0 > and forcing it to f32, but it complains that result and the op value types > are incorrect. If...

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

...re are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeting has different performance constraint...