This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11/13/2014 6:02 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson <> 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]