> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > From: David Greene <dag at cray.com> > Sent: Wednesday, July 3, 2019 2:44 PM > To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> > Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM > > Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> In addition to that, we shouldn't limit complex types to floating >>> point only. What we care about is keeping the "ac-bd" together, not >>> what type a,b,c,d are. >> >> Can you give some examples of non-FP types where a higher-level representation would be useful? > > Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.).How difficult are these to pattern match on scalar code? -Chris
On 2019-07-04 03:06, Chris Lattner via llvm-dev wrote:> >> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> -----Original Message----- >> From: David Greene <dag at cray.com> >> Sent: Wednesday, July 3, 2019 2:44 PM >> To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> >> Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> >> Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM >> >> Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >>>> In addition to that, we shouldn't limit complex types to floating >>>> point only. What we care about is keeping the "ac-bd" together, not >>>> what type a,b,c,d are. >>> Can you give some examples of non-FP types where a higher-level representation would be useful? >> Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.).Our downstream target would also benefit from this, for both complex integer and complex fixed-point operations. Just having an integer representation would be fine even for the latter case though, so long as it was generic (complex iN, for any N).> How difficult are these to pattern match on scalar code?Typically matching patterns like complex multiplication are very sensitive to noise introduced by other optimizations. Having the scalar patterns change even slightly from what the frontend emits makes selecting the operations much harder. They usually involve complex diamonds and multi-result patterns that ISelDAG has trouble with even today. Having an explicit type representation would also make it easier to keep the complex values together as one. Clang's struct-pair representation today is often broken up by SROA even though it might have been more desirable to keep the real and imaginary parts together in the same register. That's harder to accomplish when all LLVM knows is that it's a struct. / Bevin
Bevin Hansson via llvm-dev <llvm-dev at lists.llvm.org> writes:> On 2019-07-04 03:06, Chris Lattner via llvm-dev wrote: >> >> How difficult are these to pattern match on scalar code? > > Typically matching patterns like complex multiplication are very > sensitive to noise introduced by other optimizations. Having the scalar > patterns change even slightly from what the frontend emits makes > selecting the operations much harder. They usually involve complex > diamonds and multi-result patterns that ISelDAG has trouble with even today. > > Having an explicit type representation would also make it easier to keep > the complex values together as one. Clang's struct-pair representation > today is often broken up by SROA even though it might have been more > desirable to keep the real and imaginary parts together in the same > register. That's harder to accomplish when all LLVM knows is that it's a > struct.That matches my experience as well. A higher-level representation is useful even for scalar. -David
-----Original Message----- From: Chris Lattner <clattner at nondot.org> Sent: Wednesday, July 3, 2019 8:06 PM To: Krzysztof Parzyszek <kparzysz at quicinc.com> Cc: David Greene <dag at cray.com>; llvm-dev at lists.llvm.org Subject: [EXT] Re: [llvm-dev] RFC: Complex in LLVM>> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hexagon has instructions to do complex multiplication on pairs i16 x i16 (plus variants like accumulate, conjugate, etc.). > > How difficult are these to pattern match on scalar code?I can only echo what others have already written---if the complex operation is isolated, it's not too hard, but when there are other calculations involved, (such as ... + cmpy(expr1, expr2) + ...), then it becomes highly dependent on what the surrounding code looks like. Our customers use Hexagon-specific builtins when they need these instructions to be generated. Another issue with patterns is that complex operations really produce two values. One approach could be to match the real and the imaginary parts separately and hope that both generate the same instruction (there will be two of them, but they will be commoned). If that fails, we may end up with a complex instruction for only one part and a redundant calculation for the other. -Krzysztof