[LLVMdev] Thoughts about the llvm architecture -

[Jochen Wilhelmy]

>>>> 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)
and therefore have to implement my own lower. Or do you
a better idea for this?

-Jochen