[LLVMdev] Thoughts about the llvm architecture -

[Helge Rhodin]

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)
> 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.

--Helge