[PATCH] Allow loop vectorization with llvm.lifetime calls

[Arnold Schwaighofer]

Committed as r187825.

Thanks Marc!

On Aug 6, 2013, at 11:23 AM, Nadav Rotem <nrotem at apple.com> wrote:

> LGTM. 
> 
> On Aug 6, 2013, at 7:50 AM, Jessome, Marc <marc.jessome at intel.com> wrote:
> 
>> I've expanded the test, and taught the cost model about lifetime intrinsics. The call itself is scalarized, rather than reconstructed and output.
>> 
>> Marc
>> 
>> From: Nadav Rotem [mailto:nrotem at apple.com] 
>> Sent: Friday, August 02, 2013 2:54 PM
>> To: Jessome, Marc
>> Cc: llvm-commits at cs.uiuc.edu; Arnold Schwaighofer
>> Subject: Re: [PATCH] Allow loop vectorization with llvm.lifetime calls
>> 
>> The lifetime marker sequence below is legal and the stack-coloring code should not have a problem handling it.  
>> 
>> Thanks for working on this!
>> 
>> Nadav
>> 
>> On Aug 2, 2013, at 7:05 AM, Jessome, Marc <marc.jessome at intel.com> wrote:
>> 
>> 
>> Hi Nadav,
>> 
>> I'd like to continue with this patch before it falls through the cracks; Would you be able to give any insight on this remaining question?
>> 
>> 
>> The question then remains whether to subsequent calls to a lifetime intrinsic are legal. I don't see anything in "http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic" that leads me to believe it would not be.
>> 
>> +  %0 = bitcast [1024 x i32]* % arr to i8*
>> +  call void @llvm.lifetime.start(i64 4, i8* %0) #1
>> +  call void @llvm.lifetime.start(i64 4, i8* %0) #1
>> 
>> Maybe Nadav knows?
>> 
>> Thanks,
>>  Marc
>> ________________________________________
>> From: Arnold Schwaighofer [aschwaighofer at apple.com]
>> Sent: Wednesday, July 31, 2013 3:08 PM
>> To: Jessome, Marc
>> Cc: llvm-commits at cs.uiuc.edu; Nadav Rotem
>> Subject: Re: [PATCH] Allow loop vectorization with llvm.lifetime calls
>> 
>> On Jul 31, 2013, at 1:34 PM, Jessome, Marc <marc.jessome at intel.com> wrote:
>> 
>> 
>> Hi Arnold,
>> 
>> I've attached an updated patch, however I do have a quick question about one of your comments.
>> 
>> Your comment about the need to use getVectorValue() rather than getArgOperand() is spot on. I am wondering, however, if we want to do this only for the first element of the vector, or if it should be done for each element?
>> In the latter case, a simple scalarizeInstruction() would suffice, rather than manually extracting the arguments and rebuilding lifetime.* calls.
>> 
>> I was (probably mistakenly) assuming that we cannot have loop variant pointers as argument to lifetime intrinsic calls. For example:
>> 
>> +for.body:
>> +  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
>> +  %0 = getelementptr [1024 x i32]* %arr, 0, indvars.iv
>> +  %1 = bitcast [1024 x i32]* %0 to i8*
>> +  call void @llvm.lifetime.start(i64 4, i8* %1) #1
>> 
>> 
>> If we can have a construct like the one above (which I don't see why we shouldn't) then yes you need to scalarize the elements of getVectorValue() individually like done by scalarizeInstruction.
>> 
>> The question then remains whether to subsequent calls to a lifetime intrinsic are legal. I don't see anything in "http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic" that leads me to believe it would not be.
>> 
>> +  %0 = bitcast [1024 x i32]* % arr to i8*
>> +  call void @llvm.lifetime.start(i64 4, i8* %0) #1
>> +  call void @llvm.lifetime.start(i64 4, i8* %0) #1
>> 
>> Maybe Nadav knows?
>> 
>> <vectorize_lifetime.4.patch>