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: Richard Biener <richard dot guenther at gmail dot com>
- To: David Wohlferd <dw at limegreensocks dot com>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>, 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: Fri, 14 Nov 2014 11:05:44 +0100
- 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> <546543FA dot 4020002 at LimeGreenSocks dot com>
On Fri, Nov 14, 2014 at 12:51 AM, David Wohlferd <email@example.com> wrote:
> On 11/13/2014 6:02 AM, Richard Biener wrote:
>> On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson <firstname.lastname@example.org>
>>> 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
>>>> (and most sizes under 16 bytes) makes this feature all but useless. So
>>>> 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
>>>> to work right, but I have no idea what might be involved in that.
>>>> 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
>>>> to start work on the doc patch as soon as someone lets me know what the
>>>> 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?
Can you please file a bug in bugzilla if you haven't already done so?
We can still fix bugs during the next three months ;)
> 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
> - 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.
We can at least improve the docs and fix the bogus examples therein.
> - 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.
I'd say that's highly unlikely.