similar to: [LLVMdev] Promoting i16 load to i32

Hi, I am trying to complete the hardware multiplier option for MSP430 backend. As the hardware multiplier in most of the MSP430 devices is for i8 and i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. However, the front-end promotes the i8 argument to i32, executes 32-bit multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 but MUL_I32, wchich is lowered

Hi all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

On Thu, Sep 08, 2011 at 11:15:06AM -0500, Villmow, Micah wrote: > Peter, > Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. There are two main reasons why I think we shouldn't go for global flags: 1) It becomes difficult if not impossible to correctly link

The topic of Ra and jit has come up on this list recently (see http://www.milbo.users.sonic.net/ra/index.html) so I thought people might be interested in this little demo. For it I used my machine, a 3-year old laptop with 2Gb memory running Windows XP, and the good old convolution example, the same one as used on the web page, (though the code on the web page has a slight glitch in it). This

Hi, I noticed that when dividing with signed 8-bit values the IR uses a 32-bit signed divide, however, when unsigned 8-bit values are used the IR uses an 8-bit unsigned divide. Why not use a 8-bit signed divide when using 8-bit signed values? Here is the C code and IR: char idiv8(char a, char b) { char c = a / b; return c; } define signext i8 @idiv8(i8 signext %a, i8 signext %b) nounwind

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

Hello everyone, please I need your help. To reproduce my problem I created simple pass for backends (TestPass.cpp in attached files). That pass I call from Mips backend in this way (MipsTargetMachine.cpp): bool MipsPassConfig::addPreRegAlloc() { addPass(createTestPass()); return false; } The problem becomes, when I am trying compile file ldtoa.ll (in attached files). Compiling

Ok, so I think I've mis-represented what's really happening. Ignore my previous statements concerning %add :) Again, given: 05: for.body: ; preds = %entry, %for.body 06: %j.04 = phi i32 [ 0, %entry ], [ %inc, %for.body ] 07: %result.03 = phi i32 [ 0, %entry ], [ %add, %for.body ] 08: %conv2 = and i32 %result.03, 255 09: %add = add nsw

Hello all, I wanted to get some feedback on this patch for ScalarEvolution. It addresses a performance problem I am seeing for simple benchmark. Starting with this C code: 01: signed char foo(void) 02: { 03: const int count = 8000; 04: signed char result = 0; 05: int j; 06: 07: for (j = 0; j < count; ++j) { 08: result += (result_t)(3); 09: } 10: 11: return result; 12: } I

On Thu, Dec 20, 2012 at 8:36 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > Ok, so I think I've mis-represented what's really happening. > Ignore my previous statements concerning %add :) > > Again, given: > > 05: for.body: ; preds = %entry, > %for.body > 06: %j.04 = phi i32 [ 0, %entry ], [ %inc, %for.body

If I have an '&' operator inside an 'if' statement, LLVM seems to always promote a 16 bit integer type to a 32 bit integer type. I don't want this to happen because my back-end only supports 16 bit types. Why is this happening? Where might this be happening, so I can fix it? It doesn't seem to happen with the '|' operator, only '&'. Thanks!

Hello, I'm developing a llvm backend. It seems that, if i16 is not a legal type (no register can hold i16 types in RegisterInfo.td and as a RegisterClass in SelLowering.cpp), i16 should be promoted to i32. Nonotheless, this simple program: int main(){ volatile short a; a= 3; return 0; } which is trasformed in this IR: define i32 @main() nounwind readnone { entry: %a = alloca i16,

In my language there are a lot of i16 definitions, but almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases

Ahmed, Yes, this is the case, I'm sure many other 'spots' in DAGCombiner use this same check or use a similar check with LegalOperations. It just seems like bad form to have core code that generates an illegal node that legalization cannot seem to handle, unless I'm missing something, which is entirely possible. Potentially we are using the wrong LegalAction, though each I've

I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8 to compute IncrementSize, which is the offset for the load of second half of the vector. I have a situation where the frontend is producing load for a <2 x i1> type, and the architecture has i1 registers (but not v2i1 registers). The store size of i1 is

I'm trying to fix a longstanding bug with library function calls on platforms where int is passed sign-extended in a register (it badly affects SystemZ, and has a chance of affecting PowerPC64, SPARC64, MIPS64 as well). The problem is that, on these platforms, C int corresponds to a "i32 signext" parameter, but all LLVM passes inserting library calls currently use just

My two-address target machine has sign-extension instructions to extend i8->i32 and i16->i32. When I compile this simple program: int sext (unsigned a, unsigned b, int c) { return (signed char) a + (signed short) b + c; } I get this IR: define i32 @sext(i32 %a, i32 %b, i32 %c) nounwind readnone { entry: %conv = trunc i32 %a to i8 ; <i8>

Since Clang does not seem to allow type casts, such as uchar4 to float4, between vector types, it seems it is necessary to write them as element by element conversions, such as typedef float float4 __attribute__((ext_vector_type(4))); typedef unsigned char uchar4 __attribute__((ext_vector_type(4))); float4 to_float4(uchar4 in) { float4 out = {in.x, in.y, in.z, in.w}; return out; } Running

On Thu, Mar 1, 2012 at 1:04 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hello everyone, > >  I am working on some changes to the Hexagon VLIW PreRA scheduler, and as a > part of it need to test aliasing properties of two instruction. > What it boils down to is the following code: > > char a[20]; > char s; > char *p, *q; // p == &a[0]; q == &s; >

Dan, Thanks for the response ... On 12/17/2012 1:53 PM, Dan Gohman wrote: > On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote: >> Hello all, >> >> I wanted to get some feedback on this patch for ScalarEvolution. >> >> It addresses a performance problem I am seeing for simple benchmark. >> >> Starting with this C