search for: vector_input

...nts of %a? Something like @llvm.reduce(ext <N x double> ( add <N x float> %a, zeroinitializer)) Don't we have a problem with constant propagation in this approach? I proposed a "generic" intrinsic approach on the BOF (Nov, 2016), like %scalar = @llvm.reduce(OPCODE, %vector_input) - OPCODE may be a string, integer or metadata. - Elena -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Wednesday, February 01, 2017 12:54 To: Demikhovsky, Elena <elena.demikhovsky at intel.com> Cc: Amara Emerson <amara.emerson at gmail.com>;...

...ions. Your zeroinit is the thing I was looking for. > Don't we have a problem with constant propagation in this approach? I'm not sure. Can you expand this? > I proposed a "generic" intrinsic approach on the BOF (Nov, 2016), like > %scalar = @llvm.reduce(OPCODE, %vector_input) - OPCODE may be a string, integer or metadata. I wouldn't use metadata. Integer would be cumbersome and lead to eventual ABI breakages, and "text" would be the same as: %scalar = @llvm.reduce.add(%vector) which is the same thing Amara proposed. I'm not saying it is wrong, I...

> If you mean "patterns may not be matched, and reduction instructions will not be generated, making the code worse", then this is just a matter of making the patterns obvious and the back-ends robust enough to cope with it, no? The Back-end should be as robust as possible, I agree. The problem that I see is in adding another kind of complexity to the optimizer that works between the