This is the mail archive of the
mailing list for the GCC project.
Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: y dot gribov at samsung dot com, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>
- Date: Thu, 13 Nov 2014 15:51:22 -0800
- Subject: Re: [RFD] Using the 'memory constraint' trick to avoid memory clobber doesn't work
- Authentication-results: sourceware.org; auth=none
- References: <5422761C dot 2010507 at LimeGreenSocks dot com> <CAFiYyc17coKQ71HcupK5ciabRzzrcTeN2xPJ3zsTPs5BboqSyg at mail dot gmail dot com> <5423C5F2 dot 80509 at samsung dot com> <542541D9 dot 400 at LimeGreenSocks dot com> <CAFiYyc0gqKpCYGi3eLLuo8uPuvN+mDCC7Qr2X0yinNP3AEgedQ at mail dot gmail dot com> <542E4507 dot 7060200 at LimeGreenSocks dot com> <CAFiYyc0o3t1EkZ9VmRHxDjTiJvem+_qF4=ie72Gpm2yq1LTmvg at mail dot gmail dot com> <54649DFD dot 2030000 at LimeGreenSocks dot com> <alpine dot BSF dot 2 dot 02 dot 1411130846300 dot 16267 at arjuna dot pair dot com> <CAFiYyc2AQFnMydiMjVjraL_bOnH4jfperYWTuWLhrpMNxSHQ+g at mail dot gmail dot com>
On 11/13/2014 6:02 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson <email@example.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
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
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
Since (as I understand it) 5.0 docs *can* be checked in after the 15th,
- 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
- 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.