On Fri, 5 Jul, 2019, 4:50 PM Richard Biener, <richard.guent...@gmail.com>
wrote:

> On Fri, Jul 5, 2019 at 1:08 AM Akshat Garg <xks...@gmail.com> wrote:
> >
> > On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek <ja...@redhat.com> wrote:
> >>
> >> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> >> > > I think fully guaranteeing this is hard (besides when you use
> >> > > volatile), we have the very same issue when dealing with
> >> > > pointer provenance rules, known for years and not fixed
> >> > > (and I don't see a good way to fix these issues without
> >> > > sacrifying performance everywhere).
> >> > >
> >> > > Good luck ;)
> >> >
> >> > Thank you, we will need it!  ;-)
> >>
> >> Well, luck probably isn't all you need, you'll need some way to
> represent
> >> those dependencies in the IL (both GIMPLE and RTL) that would ensure
> that
> >> they aren't optimized away, because just hoping that optimization don't
> mess
> >> that up or just patching a few optimizations you discover first isn't
> going
> >> to be very reliable.  Say don't rewrite those into SSA form and
> represent
> >> them close to how volatile ptrs are handled at least for the beginning,
> and
> >> if there are safe optimizations special case those, rather than
> allowing all
> >> optimizations on those and hope it will work out.
> >>
> >>         Jakub
> >
> > I don't understand this statement completely "Say don't rewrite those
> into SSA form and represent them close to how volatile ptrs are handled at
> least for the beginning, and if there are safe optimizations special case
> those, rather than allowing all optimizations on those and hope it will
> work out.".
> > Are you saying that we should try to represent dependent ptrs as
> volatile ptrs for some places?  We should figure out all the places where a
> check for volatile ptrs happens and we check for dependent ptrs there also
> and see if we can allow the optimization or not.
> > Am I getting you correctly, please tell?
>
> I think Jakub means not to use volatile as is but mimic some of its
> properties (like we do not rewrite volatile
> vars into SSA form which fends off most optimizations turing data
> dependences into crontrol dependences,
> not all speculation though).
>
> I think "fixing" the GIMPLE optimizers to not mess up is possible even
> with SSA (just a bit tedious and fragile),
> but real issues will start at the RTL level where you completely lose
> properties like "this is a [dependent] pointer".
>
> Richard.
>
Thank you, Richard and Jakub, both for giving your valuable suggestions and
directions.

Akshat

>
> >
> > -Akshat
>

Reply via email to