[llvm-dev] Assigning constant value without alloca/load/store

[George Burgess IV via llvm-dev]

> But since something like that (bitcast constant) is allowed why isn't it
possible to simply do this

The following code

%1 = i32 1
%2 = i32 2
%3 = add i32 %1, %2

is more or less equivalent to

%1 = add i32 1, 2

Because, in most cases, Instructions don't care if they're given SSA Values
or Constants as operands. The second version is more compact, more concise,
and has less indirection than the first, so it's presumably better in the
vast majority of cases.

Is there something you're trying to work around with the 'Initializing
registers' bit of your initial example? ISTM that doing so would be
entirely unnecessary if you took Jeremy's approach (well, a simplified
version of it; you'd only need to do most of step 2 if you're guaranteed to
only have a single basic block).

On Mon, Feb 8, 2016 at 5:09 AM, mats petersson <mats at planetcatfish.com>
wrote:

> Is there some particular reason that short IR is better than "follow what
> others do"?
>
> I have written a (reasonably complete) Pascal compiler, and at first I
> worried about calling alloca, but I found that the mem2reg does a very good
> job of getting rid of alloca's, so it's not really a problem [you just need
> to ensure that all alloca's happen at the start of the function, or weird
> things happen, from what I've heard].
>
> --
> Mats
>
> On 8 February 2016 at 11:01, Paul Peet via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I want to keep the translation short and simple (My IR doesn't have
>> control flow so it's basically on basic block) that's why I don't want to
>> rely on alloca/load/store.
>>
>> 2016-02-08 6:08 GMT+01:00 George Burgess IV <george.burgess.iv at gmail.com>
>> :
>>
>>> Hi!
>>>
>>> I don't know what "the right way" to do this is, but is there any reason
>>> you're against just using alloca/load/store? That's what clang emits for
>>> most locals/parameters/..., and LLVM tends to do a very good job of
>>> SSAifying that where it can. :)
>>>
>>> George
>>>
>>> On Sun, Feb 7, 2016 at 3:00 PM, Paul Peet via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am currently trying to translate some custom IR to LLVM-IR and came
>>>> across and issue.
>>>> The custom IR has several registers and I am basically try to SSAfy it
>>>> so it can be easily translated/converted to LLVM-IR.
>>>>
>>>> The problem:
>>>>
>>>> Since in my custom IR I can reassign every register I have to reassign
>>>> every new expression with a new llvm Value. But my IR has something like
>>>> this:
>>>>
>>>> REG A = VAR C + CONST 2
>>>> REG A = CONST 12
>>>>
>>>> So my workaround looks like:
>>>>
>>>> ; I am returning the registers in an anonymous struct
>>>> define { i32, i32, i32 } @test(i32 %var_c) {
>>>>   ; Initializing registers
>>>>   %reg_a_0 = select i1 true, i32 0, i32 0
>>>>   %reg_b_0 = select i1 true, i32 0, i32 0
>>>>   %reg_c_0 = select i1 true, i32 0, i32 0
>>>>
>>>>   ; Translated instructions
>>>>   %reg_a_1 = add i32 %var_c, 2
>>>>   %reg_a_2 = select i1 true, i32 12, i32 0
>>>>
>>>>   ; Prepare return values
>>>>   %ret_0 = insertvalue { i32, i32, i32 } undef, i32 %reg_a_2, 0
>>>>   %ret_1 = insertvalue { i32, i32, i32 } %ret_0, i32 %reg_b_0, 1
>>>>   %ret_2 = insertvalue { i32, i32, i32 } %ret_1, i32 %reg_c_0, 2
>>>>
>>>>   ret { i32, i32, i32 } %ret_2
>>>> }
>>>>
>>>> I am basically using "select i1 true, i32 1, i32 0" so after
>>>> optimization it gets:
>>>> %val = i32 1
>>>>
>>>> But as I said this looks like a hack to me and I can't simply use "%val
>>>> = i32 1".
>>>> So what's the proper way to do this without actually using
>>>> alloca/load/store.
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> 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/20160208/0357acbf/attachment.html>