3 ms·
> ... not every platform has "process 4 floats at once this way Sure. The point is - you can write IR code that multiplies _any_ number of floats and the backe
by majke 13y ago
> ... not every platform has "process 4 floats at once this way
Sure. The point is - you can write IR code that multiplies _any_ number of floats and the backend "should" generate reasonable machine code for any architecture.
> Also I don't see the encoding of assumptions of alignment
Yeah, no memory loads there, data passed in xmm0 and xmm1, plenty of simplifications.
> The another topic is how often IR is going to change.
Fair question. I don't know but given the number of projects that currently use it I'm quite sure it'll be well maintained. Also, keep in mind that adapting IR to a future version (if one is created) is still IMO simpler than adapting assembler. Additionally - you can use IR to generate machine code once (for every architecture). That way you won't depend on your users having LLVM installed.
- cliffbean 13y ago> you can write IR code that multiplies _any_ number of floats and the backend "should" generate reasonable machine code for any architecture. Except that it doesn't. If you write your code with <2 x float> and codegen for SSE, you'll get <4 x float> code, with two elements going unused. It's functionally correct, but you're potentially missing out on half the throughput. If you write your code with <8 x float>, you'll get two registers for each value, but this can create extra register pressure without actually giving you any increased throughput in return.
- jevinskie 13y agoOther optimization passes will widen the vecorization width to 4 if possible by unrolling the loop!