Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work

[David Wohlferd <dw at LimeGreenSocks dot com>]

On 11/13/2014 6:02 AM, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > On Thu, 13 Nov 2014, David Wohlferd wrote:
> > > Sorry for the (very) delayed response.  I'm still looking for feedback here so
> > > I can fix the docs.
> > Thank you for your diligence.
> >
> > > As I said before, triggering a full memory clobber for anything over 16 bytes
> > > (and most sizes under 16 bytes) makes this feature all but useless.  So if
> > > that's really what's happening, we need to decide what to do next:
> > >
> > > 1) Can this be "fixed?"
> > > 2) Do we want to doc the current behavior?
> > > 3) Or do we just remove this section?
> > >
> > > I think it could be a nice performance win for inline asm if it could be made
> > > to work right, but I have no idea what might be involved in that.  Failing
> > > that, I guess if it doesn't work and isn't going to work, I'd recommend
> > > removing the text for this feature.
> > >
> > > Since all 3 suggestions require a doc change, I'll just say that I'm prepared
> > > to start work on the doc patch as soon as someone lets me know what the plan
> > > is.
> > >
> > > Richard?  Hans-Peter?  Your thoughts?
> > I've forgot if someone mentioned whether we have a test-case in
> > our test-suite for this feature.

I'm looking thru gcc/testsuite/*.c to see if I can spot anything. It's 
not easy since there is a lot of asm and the people who write these are 
apparently allergic to using comments to describe what they are testing.

> > If we don't, then 3; removal.
> > If we do, I guess it's flawed or at least not agreeing with the
> > documentation?  Then it *might* be worth the effort fixing that
> > and additional test-coverage (depending on the person stepping
> > up...) but 3 is IMHO still an arguably sane option.
> Well, as what is missing is just an optimization I'd say we should
> try to fix it.

While I'd love to be the one to fix this, the fact of the matter is that 
most of gcc is a black box to me.  Even if you told me roughly where to 
start, I'd have no idea of the downstream impacts of anything I changed.

So while I understand that it looks like I'm just finding work for other 
people, fixing something like this is simply beyond me.  That said, I'm 
certainly prepared to outline what I see as the interesting test cases 
and to do some testing if someone else is willing to step up and do this 
optimization.

> And surely the docs should not promise that optimization
> will happen - it should just mention that doing this might allow
> optimization to happen.

I can agree with this.  I am quite confident there will be occasions 
where gcc has no option but to fall back to doing a full clobber to 
ensure correct function (a possibility which the current docs also fails 
to mention).  So yes, the docs should be limited in what it promises here.

Which brings us to the question: what do we do now?  The 15th is fast 
approaching.  Can something like this get done before then? Can it be 
checked in for 5.0 after the 15th?  Or does it need to wait for 6.0?

If it does need to wait for 6.0, what do we want to do with the docs in 
the meantime?  Given how wrong they are currently, I'd hate to ship yet 
another release with that ugly text.  But trying to describe the best 
way to take advantage of optimizations that haven't been written yet 
is... hard.

Since (as I understand it) 5.0 docs *can* be checked in after the 15th, 
my recommendations:

 - If someone is prepared to step up and do this work for v5.0, then 
I'll wait and write the docs when they are done and can describe how it 
works.
 - If this is going to wait for 6.0, then if someone does (at least) 
enough investigative work to be able to describe how this will 
eventually work, I'll update the 5.0 docs in a general way talking about 
ways gcc *may* be able to optimize.  It should be possible to phrase 
this so code people write today will work even better tomorrow.
 - Worst case is if no one has the time to look at this for the 
foreseeable future.  In that case, I'm with Hans-Peter.  Let's take the 
existing text out.  Following the existing text makes things *worse*, 
and the current implementation is so limited that I'd be surprised if 
anyone's code actually uses it successfully.  New text can get added 
when the new code is.

Hmm.  I just had a thought: Is it possible the problem I'm seeing here 
is platform-specific?  Maybe this works perfectly for non-i386 code?  
That would certainly change my recommendations here.

dw