On Fri, Nov 14, 2014 at 12:51 AM, David Wohlferd <d...@limegreensocks.com> wrote: > > On 11/13/2014 6:02 AM, Richard Biener wrote: >> >> On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson <h...@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?
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. Richard. > dw
