On 04/25/2014 02:21 PM, Eric Christopher wrote:>> In short, I agree with your observations that these intrinsics are not an >> obvious slam-dunk compared to making the explicit control flow, but I think >> that the intrinsics do give enough flexibility on the LLVM side that it >> would be great if front-ends used them rather than rolling the control flow >> themselves. >> > The problem is that then we have 2 problems: All targets (except for > arm64) then have to lower the intrinsic as the first thing they do > (giving us a TTI pass as the first thing in the pipeline) to take > advantage of the information later during optimization, _and_ we have > to plumb all of the work optimizing the intrinsic as well giving us a > situation where we've now split our optimization efforts as well as > the pain of maintaining an intrinsic that's useful for a single > target. > > I really think that this is just solidifying my position that the > intrinsic is a bad idea and that this should be done as later > optimizations. > > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevDoes anyone have performance data on ARM for the early vs late lowering approaches? Having data would make the discussion much more concrete about the tradeoffs of the two approaches. To put it another way, how much do we loose performance-wise in missed pattern matching? Philip
Eric Christopher
2014-Apr-25 23:18 UTC
[LLVMdev] Proposal: add intrinsics for safe division
On Fri, Apr 25, 2014 at 3:55 PM, Philip Reames <listmail at philipreames.com> wrote:> > On 04/25/2014 02:21 PM, Eric Christopher wrote: >>> >>> In short, I agree with your observations that these intrinsics are not an >>> obvious slam-dunk compared to making the explicit control flow, but I >>> think >>> that the intrinsics do give enough flexibility on the LLVM side that it >>> would be great if front-ends used them rather than rolling the control >>> flow >>> themselves. >>> >> The problem is that then we have 2 problems: All targets (except for >> arm64) then have to lower the intrinsic as the first thing they do >> (giving us a TTI pass as the first thing in the pipeline) to take >> advantage of the information later during optimization, _and_ we have >> to plumb all of the work optimizing the intrinsic as well giving us a >> situation where we've now split our optimization efforts as well as >> the pain of maintaining an intrinsic that's useful for a single >> target. >> >> I really think that this is just solidifying my position that the >> intrinsic is a bad idea and that this should be done as later >> optimizations. >> >> -eric >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Does anyone have performance data on ARM for the early vs late lowering > approaches? Having data would make the discussion much more concrete about > the tradeoffs of the two approaches. > > To put it another way, how much do we loose performance-wise in missed > pattern matching? >There were no performance or optimization numbers provided with the patch or proposal :) -eric
On 04/25/2014 04:18 PM, Eric Christopher wrote:> On Fri, Apr 25, 2014 at 3:55 PM, Philip Reames > <listmail at philipreames.com> wrote: >> On 04/25/2014 02:21 PM, Eric Christopher wrote: >>>> In short, I agree with your observations that these intrinsics are not an >>>> obvious slam-dunk compared to making the explicit control flow, but I >>>> think >>>> that the intrinsics do give enough flexibility on the LLVM side that it >>>> would be great if front-ends used them rather than rolling the control >>>> flow >>>> themselves. >>>> >>> The problem is that then we have 2 problems: All targets (except for >>> arm64) then have to lower the intrinsic as the first thing they do >>> (giving us a TTI pass as the first thing in the pipeline) to take >>> advantage of the information later during optimization, _and_ we have >>> to plumb all of the work optimizing the intrinsic as well giving us a >>> situation where we've now split our optimization efforts as well as >>> the pain of maintaining an intrinsic that's useful for a single >>> target. >>> >>> I really think that this is just solidifying my position that the >>> intrinsic is a bad idea and that this should be done as later >>> optimizations. >>> >>> -eric >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> Does anyone have performance data on ARM for the early vs late lowering >> approaches? Having data would make the discussion much more concrete about >> the tradeoffs of the two approaches. >> >> To put it another way, how much do we loose performance-wise in missed >> pattern matching? >> > There were no performance or optimization numbers provided with the > patch or proposal :) > > -ericAgreed. That was my point. :) Philip