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. -Jochen
On Jul 29, 2010, at 5:24 AM, Jochen Wilhelmy wrote:> 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? -Chris
>> 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? I think I still miss some of the "big picture". Is there an architecture chart that shows the pipeline stages of llvm and what is done where? For example it seems that ligalization takes place after instcombine, but I would think it should happen before instcombine. -Jochen