Displaying 4 results from an estimated 4 matches for "idxprom2".
Did you mean:
idxprom
2013 Aug 11
0
[LLVMdev] Address space extension
...re readonly
%mask, i32* nocapture %output) #0 {
entry:
%call = tail call i32 @get_global_id(i32 0) #2
%idxprom = zext i32 %call to i64
%arrayidx = getelementptr inbounds i32* %input, i64 %idxprom
%0 = load i32* %arrayidx, align 4, !tbaa !1
%call1 = tail call i32 @get_local_id(i32 0) #2
%idxprom2 = zext i32 %call1 to i64
%arrayidx3 = getelementptr inbounds i32* %mask, i64 %idxprom2
%1 = load i32* %arrayidx3, align 4, !tbaa !1
%add = add nsw i32 %1, %0
%arrayidx5 = getelementptr inbounds i32* %output, i64 %idxprom
store i32 %add, i32* %arrayidx5, align 4, !tbaa !1
ret void
}
As...
2013 Jun 26
0
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
Sent from my iPhone...
On Jun 25, 2013, at 8:14 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>>
>>
>>
>> On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote:
>>
>>
>>
>>
>> Indvars should ideally preserve NSW flags whenever possible. However,
>> we don't want to
2013 Aug 10
2
[LLVMdev] Address space extension
> -----Original Message-----
> From: Michele Scandale [mailto:michele.scandale at gmail.com]
> Sent: Saturday, August 10, 2013 6:29 AM
> To: Micah Villmow
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
>
> On 08/10/2013 02:47 PM, Micah Villmow wrote:
> > Michele,
> > The information you are trying to gather is fundamentally
2013 Jun 25
2
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
----- Original Message -----
>
>
>
> On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote:
>
>
>
>
> Indvars should ideally preserve NSW flags whenever possible. However,
> we don't want to rely on SCEV to preserve them. SCEV expressions are
> implicitly reassociated and uniqued in a flow-insensitive universe
> independent of the