[LLVMdev] Thoughts about the llvm architecture -

ether zhhb etherzhhb at gmail.com
Sat Sep 4 20:13:14 PDT 2010


hi,

On Sun, Sep 5, 2010 at 12:24 AM, Helge Rhodin
<helge.rhodin at alice-dsl.net> wrote:
> Jochen Wilhelmy schrieb:
>>>>>> Hi!
>>>>>>
>>>>>> The following thoughts about the llvm architecture I'd like to share
>>>>>> with you
>>>>>> (from the perspective of a user):
>>>>>>
>>>>>> - If a backend has no vector support, then I wonder why there is no
>>>>>> de-vectorization
>>>>>> pass that operates on indermediate llvm-ir. I would think that if you
>>>>>> use such a target
>>>>>> then you have to insert a target independent pass before it that it does
>>>>>> not have to
>>>>>> care about vector code. The advantage is that constant vector components
>>>>>> can already
>>>>>> be handled by instcombine. what do you think?
>>>>>>
>>>>>> - If the integer width of a backend is smaller than the integers in the
>>>>>> llvm-ir (e.g.
>>>>>> an 8 bit microcontroller) then i also would expect a target independent
>>>>>> integer
>>>>>> splitting.  the difficulty here is how to handle carry in the ir. but the
>>>>>> advantage would
>>>>>> be that if i have e.g. int32_t a = 5 then three of the four bytes are
>>>>>> zero and can
>>>>>> be optimized by instcombine. I have seen very bad code in the output of
>>>>>> avr-gcc in this case.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Legalize and DAG combine already handle these cases.  Why would we want to duplicate the code?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> But what is the output of legalize and DAG combine? Is it llvm-ir again?
>>>>
>>>>
>>>>
>>> No, the output after legalize and DAG combine are a modified selection
>>> DAG graph.
>>> This selection DAG graph later gets converted into MachineInstrs after
>>> scheduling.
>>>
>>>
>>
>> then it seems this is done:
>> instCombine (on llvm ir)
>> llvm ir -> selection dag
>> lower
>> combine
>> legalize
>> combine
>> ...
>>
>> I wonder if there is duplicate code in instCombine (on llvm ir, e.g.
>> llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp)
>> and combine on selection dag, and worst of all I can't use
>> lower since I write llvm ir into highlevel code (like CBackend)
i encounter the same problem,  i build my own schedule DAG from LLVM
IR right now, and planning to build my schedule DAG from
pre-register-allocation MachineInst later, so i can reuse some
existing machine pass.


>> and therefore have to implement my own lower. Or do you
>> a better idea for this?
>>
>> -Jochen
> The same passes would be beneficial for my PTX backend
> implementation(also like Cbackend). Are there reasons for not
> implementing them on the llvm ir? Is the current implementation easier?
> I think a llvm ir implementation is more general.

maybe we need a "general target"  for the similar task, the
instructions in general target should be almost the same as llvm ir
instruction, and there should be maximum register available so we do
not need to care about the register stuffs.

best regards
ether
>
> --Helge
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list