Rob Suderman
Rob Suderman
> Based on the description, I'm going to start with the assumption that this is an issue with the torch to linalg conversions. Asking Rob to weigh in. So the...
> Do we know how terrible of code this generates? This is a lot of stuff to do per element and I suspect it may break vectorization and such -...
> sounds good - @MaheshRavishankar may be able to speak to the formation questions - I mostly am just curious if we're sending all scatters down a scalar path with...
> yeah, that reduction is likely to be an issue - we don't really want to serialize everything like that - is there a reason to reduce? > > (I'd...
> @rsuderman , here is the much more concise and optimized way that the PyTorch runtime does it (I think that part was written by Marat and carried over from...
Could you separate adding the formatting work / job from the actual reformatting of the code. It should help avoid conflating functional changes from purely formatting changes.
It appears the issue is in `LLVMCPUVectorTransferLowering`. There is a full unrolling making the dispatch rather unruly.
Some additional guilty lines: ``` %12 = vector.transfer_read %10[%c0, %c0], %cst_2 {in_bounds = [true, true]} : tensor, vector %13 = arith.extf %12 : vector to vector %14 = vector.transfer_write %13,...
This issue is blocking another model on the `onnx` front.
Validated that this is still failing.