[llvm-dev] LLVM IR temporary variable reuse

[Mehdi Amini via llvm-dev]

Have you read the SSA link that David sent earlier? (i.e. https://en.wikipedia.org/wiki/Static_single_assignment_form )

There is no such thing as a "LLVM register", or "variables". 
The main concepts are the memory, and  *values* (like %sub in your example). The latter are *immutable*.

-- 
Mehdi

> On Mar 18, 2016, at 2:49 AM, Ansar K.A. via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> For eg:
> 
> c=a-b is represented using the following statements in IR:
> 
>   %tmp = load i32, i32* %a, align 4
>   %tmp1 = load i32, i32* %b, align 4
>   %sub = sub nsw i32 %tmp, %tmp1 
>   store i32 %sub, i32* %c, align 4
> 
> 
> whenever there is a redundant computation of the same, say k=a-b (if the value of a and b are not changed) the code will be like this:
> 
>   %tmp2 = load i32, i32* %a, align 4
>   %tmp3 = load i32, i32* %b, align 4
>   %sub1 = sub nsw i32 %tmp2, %tmp3 
>   store i32 %sub1, i32* %k, align 4
> 
> But this is not required, Since a-b is already there in that virtual register %sub. So I can rewrite the highlighted code ( eliminating redundancy ) as
> 
>  store i32 %sub, i32* %k, align 4
> 
> and can delete the statement %sub1 = sub nsw i32 %tmp2, %tmp3 
> 
> But, If in case LLVM is reusing %sub in between to hold some other computations, then there will be some errors in my computation. So I want to make sure that LLVM won't reuse any of these virtual registers. 
> 
> I hope it clarifies.
> 
> 
> 
> On 18 March 2016 at 13:39, mats petersson <mats at planetcatfish.com <mailto:mats at planetcatfish.com>> wrote:
> 
> 
> On 18 March 2016 at 06:31, Ansar K.A. via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I meant LLVM registers. Thanks for the correcting me.
> 
> But registers in LLVM-IR are in infinite supply, since the are virtual registers. Real registers appear when the IR is translated to machine instructions, and this is based on the live-range of the actual variables, so the same register will be re-used within the machine code. Reusing a virtual register is BAD because it will confuse the IR into thinking that your code is using the same thing for longer, and thus, potentially, make it use the same hardware register when two different ones could have been used.
> 
> Can you please explain what it is you want to achieve, as a bigger picture? Ideally with some example of some source, its generated IR and how you want it to be different?
> 
> --
> Mats
> 
> On 18 March 2016 at 10:42, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
> Question is hard to understand - the registers in LLVM are in Static Single Assignment form <https://en.wikipedia.org/wiki/Static_single_assignment_form>, they're not variables that can be assigned and reassigned values (so the answer to your question is probably "no"). It's best to look at what Clang does to see how IR can be used to represent constructs in C you may be more familiar with.
> 
> On Thu, Mar 17, 2016 at 10:05 PM, Ansar K.A. via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> In any case, Is there any chance for reusing temporary variable used in it's IR by LLVM ? 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160318/92b6c217/attachment.html>