Hi all, I have a query regarding Cost Table for AVX2 in TargetTransformInfo. The table consist of entries for shift and div operations only. There are no entries for ADD, SUB and MUL for AVX2 cost table. Those entries are present in Cost Table for AVX. The reason for query is - when my sub target feature is AVX2, in SLP Vectorization, while calculating scalar cost of ADD, it doesn't see the entry in cost table and falls back to default implementation returning cost 1. While for AVX, it finds the ADD in cost table and returns 4 as scalar cost. I am suspecting this is something specific to architecture difference between AVX and AVX2. I am naive to architecture specifics in this case. I would be glad if someone clarifies on this. Thanks. Regards, Suyog Sarda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/6bef97b3/attachment.html>
> On May 4, 2015, at 2:36 AM, suyog sarda <sardask01 at gmail.com> wrote: > > Hi all, > > I have a query regarding Cost Table for AVX2 in TargetTransformInfo. > > The table consist of entries for shift and div operations only. There are no entries for ADD, SUB and MUL for AVX2 cost table. Those entries are present in Cost Table for AVX.Most of the cost information is inferred from the TargetLowering tables (where operations are marked as Legal, Custom, etc.) Only exceptional instructions need to be recorded in the TargetTransformInfo cost tables.> > The reason for query is - when my sub target feature is AVX2, in SLP Vectorization, while calculating scalar cost of ADD, it doesn't see the entry in cost table and falls back to default implementation returning cost 1. While for AVX, it finds the ADD in cost table and returns 4 as scalar cost.> > I am suspecting this is something specific to architecture difference between AVX and AVX2. I am naive to architecture specifics in this case.I assume that this is integer ADD, because AVX1 only supported floating point arithmetic on 256bit vectors, while AVX2 added support for 256bit integer arithmetic. So, it makes sense that the cost that AVX1 gives this operation is much higher.> > I would be glad if someone clarifies on this. > > Thanks. > > Regards, > Suyog Sarda
Thanks Nadav for the info. It clears my query :) Yes its an integer ADD, and since AVX2 supports 256 bits integer arithmetic, so its cost is less than AVX1. One query though - shouldn't then the cost of integer ADD/SUB/MUL (which would be 1) be explicitly specified in AVX2 cost table? Because right now this entry is missing and cost of these operations are taken from BaseTTI (which is generic). IMO, it will make things more clear. Your thoughts on this?? Regards, Suyog Sarda On 4 May 2015 21:57, "Nadav Rotem" <nrotem at apple.com> wrote:> > > On May 4, 2015, at 2:36 AM, suyog sarda <sardask01 at gmail.com> wrote: > > > > Hi all, > > > > I have a query regarding Cost Table for AVX2 in TargetTransformInfo. > > > > The table consist of entries for shift and div operations only. There > are no entries for ADD, SUB and MUL for AVX2 cost table. Those entries are > present in Cost Table for AVX. > > Most of the cost information is inferred from the TargetLowering tables > (where operations are marked as Legal, Custom, etc.) Only exceptional > instructions need to be recorded in the TargetTransformInfo cost tables. > > > > > The reason for query is - when my sub target feature is AVX2, in SLP > Vectorization, while calculating scalar cost of ADD, it doesn't see the > entry in cost table and falls back to default implementation returning cost > 1. While for AVX, it finds the ADD in cost table and returns 4 as scalar > cost. > > > > > I am suspecting this is something specific to architecture difference > between AVX and AVX2. I am naive to architecture specifics in this case. > > I assume that this is integer ADD, because AVX1 only supported floating > point arithmetic on 256bit vectors, while AVX2 added support for 256bit > integer arithmetic. So, it makes sense that the cost that AVX1 gives this > operation is much higher. > > > > > > I would be glad if someone clarifies on this. > > > > Thanks. > > > > Regards, > > Suyog Sarda > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/1a35d513/attachment.html>