This includes both GEPs where the indexed type is a scalable vector, and GEPs where the result type is a scalable vector.
I had to make a couple related fixes to allow all the testcases to compile.
Differential D73602
[SVE] Add support for lowering GEPs involving scalable vectors. efriedma on Jan 28 2020, 7:37 PM. Authored by
Details This includes both GEPs where the indexed type is a scalable vector, and GEPs where the result type is a scalable vector. I had to make a couple related fixes to allow all the testcases to compile.
Diff Detail
Event TimelineComment Actions Just noticed CodeGen/X86/large-gep-scale.ll is failing; need to tweak the ElementSize handling a bit. Comment Actions Fix regression test failure. Add a few comments to try to explain the convoluted logic for the various different bitwidths. Comment Actions Hi @eli.friedman , thank you for working on this, I am working on adding the addressing modes for SVE, this is required to be able to test what I am doing in the back-end. I have the following questions/requests.
All these requests will probably require you to add more patterns in AArch64SVEInstrInfo.td, other than the one you have already added. If that's the case, I think it will be worth splitting the patch in two patches, one for the CodeGen of the patterns and one for the codegen of the GEP (of course, unless it is not possible to reproduce such patterns without the GEP on scalable types...) Thanks! Francesco Comment Actions Hello @efriedma , I have started adding SVE reg+imm addressing mode on top of your patch (see https://reviews.llvm.org/D74254). To make it work, I had to add handling of getelementpr when adding a constant int. The hunk I have added could be useful to let you implement the extra cases I have asked you to add in this patch. Feel free to grab it as it is, or modify it if you find a better way to handle such cases. Meanwhile, I will keep working on the addressing modes. Thank you! Francesco Comment Actions
I'm not sure what you mean by "the math". A scalar GEP produces a scalar result, a vector GEP produces a vector result. A scalar operand to a vector GEP is splatted. I'm not sure what useful explanation I could add; I could add a comment "This is a vector GEP", but I'm not sure that's helpful; the result type is already explicitly written in the "ret" instruction.
Sure.
For vector GEPs, all the math always has to happen in N x i64 (since pointers are 64 bits wide). So if N>2, we have to run type legalization, and that probably explodes in unrelated ways, so I don't really want to do that. I can add more tests for scalar GEPs over vector pointee types; that shouldn't require more patterns, I think.
What's the difference between the DAG produced by your patch, vs. my patch alone?
Comment Actions Yeah, I was confused by what the GEP was doing, I thought you where somehow adding the values of the fixed length vector to the first lanes of the scalable one. My bad. No need to add any comment.
Thanks!
Yes, I was not asking to modify the types of the RHS argument, I was asking to modify the type of the base pointer, so that you tests things like getelementptr <vscale x 2 x i8>, <vscale x 2 x i8>*, i64 %whatever
I have explained it in the comment of the first example.
Comment Actions LGTM!
|
I'm not sure I understand this comment; why would ElementSize not fit into IdxTy?