[LLVMdev] [RFC][PATCH] Adding absd/hadd/sad intrinsics
Shahid, Asghar-ahmad
Asghar-ahmad.Shahid at amd.com
Wed May 6 03:21:53 PDT 2015
> For the time being, if you can get away with heuristics, and that fills your
> allocated time for this task, that it's the best way forward for now.
Sorry that I could not get what exactly you mean with "heuristics".
Is it the "intrinsics approach" itself or something else?
BTW, now my plan is to just add the two intrinsics for 'absolute difference'
and 'horizontal add'.
Regards,
Shahid
> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: Wednesday, May 06, 2015 3:22 PM
> To: Shahid, Asghar-ahmad
> Cc: James Molloy; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [RFC][PATCH] Adding absd/hadd/sad intrinsics
>
> On 6 May 2015 at 06:43, Shahid, Asghar-ahmad <Asghar-
> ahmad.Shahid at amd.com> wrote:
> > That’s right. I agree with your *pattern vs complexity* thinking.
> >
> > So I would drop llvm.sad() and go ahead with the remaining two.
> >
> > Does it make sense in general?
>
> We strive to keep things simple.
>
> Creating too many intrinsics makes the IR brittle and hard to optimise.
> Creating pattern matching rules can be complex, but they're generally
> preferred to adding intrinsics. But creating a new pattern matching engine
> just for the sake of one case is too much, so we end up using heuristics
> instead.
>
> However, heuristics are like connective tissue. They look functional, but they
> add up to a big and ineffective blob, which ends up being less effective every
> new data you add. So, in the end, having a plan to generate a more efficient
> pattern matching structure could very well reduce the amount of code, if
> (and only if), the plan accounts for most current cases as well as the new
> ones.
>
> For the time being, if you can get away with heuristics, and that fills your
> allocated time for this task, that it's the best way forward for now.
>
> cheers,
> --renato
More information about the llvm-dev
mailing list