[llvm-dev] RFC: Generic IR reductions

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 1 08:32:45 PST 2017

> On Feb 1, 2017, at 6:56 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> +CC Chandler and Philip.
> On 1 February 2017 at 08:27, Renato Golin <renato.golin at linaro.org> wrote:
>> Well, that was certainly a smaller group than the list. Design
>> decisions should not be taken off list, so we must have this
>> discussion on the list again, I'm afraid.
>>> I don't believe having many intrinsics would be a problem.
>> This is against every decision I remember. Saying it out loud in a
>> meeting is one thing, writing them down and implementing and having to
>> bear the maintenance costs is another entirely.
> That's fair. To bring some context, during Elena's BOF
> Chandler/Philip's made some arguments against the idea of general
> purpose single intrinsics that take an opcode parameter, which went
> along the lines of: the design would lower the bar for introducing new
> idioms to an extent that each one would not have to undergo as much
> scrutiny as separate additions. I specifically recall someone, and I
> think it was Chandler but correct me if I'm wrong, saying that many
> intrinsics were not in itself a problem. Their points were also
> broader than that of reductions, and covered the general approach of
> handling groups of idioms. Chandler/Philip I hope I haven't
> mischaracterized your thoughts.

I was not at the BoF but I agree with the idea that lowering the bar has undesirable side-effects.

Usually when considering the choice between the form  llvm.reduce.op(…) or llvm.reduce(op, …), I would expect the second choice to have to be motivated by the fact that there is enough interesting semantic properties that can be used by the analysis *without* understanding `op`. 
This is because it would allow to write passes / analyses that could process llvm.reduce() generically.

I’m not sure this is the case here, knowing that a reduction is performed without knowing the operation is likely not very helpful.


More information about the llvm-dev mailing list