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 Fri, Nov 14, 2014 at 12:51 AM, David Wohlferd <> wrote:
> 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
>>>> 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?

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
> 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.

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.


> dw

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