[PATCH] D38392: Disallow sinking of unordered atomic loads into loops

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 10 12:20:44 PDT 2017


There are good placement decision algorithms based on profile data (real
and static).  It is a max flow problem solvable by very simple solvers.

So if this becomes a real problem, we could solve it.

On Fri, Sep 29, 2017, 9:00 PM Philip Reames via Phabricator <
reviews at reviews.llvm.org> wrote:

> reames added a comment.
>
> In https://reviews.llvm.org/D38392#885147, @danielcdh wrote:
>
> > In https://reviews.llvm.org/D38392#885134, @reames wrote:
> >
> > > In https://reviews.llvm.org/D38392#885108, @danielcdh wrote:
> > >
> > > > I see your point now. My concern is performance: if we allow
> hoisting of atomic load, but not allow sinking it, we may end up with bad
> performance as we may have too much redundant atomic loads in the
> preheader. Any suggestions on how to solve that?
> > >
> > >
> > > Not really.  I can say that we've been running performance tests for
> months in this configuration (LICM hoisting unordered loads, no LoopSink)
> without noticing any problems.  I'm not immediately concerned.
> >
> >
> > Sorry, not sure if I follow the logic, could you explain why you don't
> think this is a performance concern?
>
>
> I acknowledge it's a potential issue.  I have no good ideas for a
> solution.  I don't believe it's a current problem and evidence to believe
> that it's relatively minor.  (i.e. we haven't seen it)
>
>
> https://reviews.llvm.org/D38392
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171010/291c32cc/attachment.html>


More information about the llvm-commits mailing list