Why doesn't combine like volatiles? (volatile_ok again, sorry!)

Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Dave Korn]

  Morning gcc-hackers!


  I was wondering why combine could piece together two insns like these:

----------------------------<snip!>----------------------------
(insn 11 5 12 0 0x1002f330 (set (reg:QI 74)
        (mem:QI (reg/v/f:SI 70) [0 S1 A8])) 25 {movqi} (insn_list 3 (nil))
    (expr_list:REG_DEAD (reg/v/f:SI 70)
        (nil)))

(insn 12 11 14 0 0x1002f330 (set (reg/v:SI 72)
        (zero_extend:SI (reg:QI 74))) 17 {zero_extendqisi2} (insn_list 11
(nil))
    (expr_list:REG_DEAD (reg:QI 74)
        (nil)))
----------------------------<snip!>----------------------------

into one like this:

----------------------------<snip!>----------------------------
(note 11 5 12 0 NOTE_INSN_DELETED)

(insn 12 11 14 0 0x1002f330 (set (reg/v:SI 72)
        (zero_extend:SI (mem:QI (reg/v/f:SI 70) [0 S1 A8]))) 17
{zero_extendqisi2} (insn_list 3 (nil))
    (expr_list:REG_DEAD (reg/v/f:SI 70)
        (nil)))
----------------------------<snip!>----------------------------

but it fails if the MEM references are volatile:

----------------------------<snip!>----------------------------
(insn 11 5 12 0 0x1002fc60 (set (reg:QI 74)
        (mem/v:QI (reg/v/f:SI 70) [0 S1 A8])) 25 {movqi} (insn_list 3 (nil))
    (expr_list:REG_DEAD (reg/v/f:SI 70)
        (nil)))

(insn 12 11 14 0 0x1002fc60 (set (reg/v:SI 72)
        (zero_extend:SI (reg:QI 74))) 17 {zero_extendqisi2} (insn_list 11
(nil))
    (expr_list:REG_DEAD (reg:QI 74)
        (nil)))
----------------------------<snip!>----------------------------

  Looking at it, this seems to be quite deliberate: combine_instructions()
calls init_recog_no_volatile() before it runs the combine pass and
init_recog() afterward.  I haven't delved into the morass of machine-generated
loveliness that is insn-recog.c, but by modifying recog_for_combine() to try
calling recog() twice, once with volatiles disabled, and once with them
enabled, I've been able to determine that that's definitely the cause that
prevents the volatile loads from being combined with the zero_extend
operations.

  All this is despite the fact that I have "#define LOAD_EXTEND_OP(MODE)
ZERO_EXTEND" in my target header file.

  I see from the archives that this has come up before.  I found loads of
mails from Mike Stump suggesting to google his name and "volatile_ok" to find
a patch, but I couldn't find it, and I couldn't get a clear impression of what
the real issue is here.

  What's a decent solution here?  Should I come up with a new version of
general_operand, call it general_or_volatile_operand, that would accept mem/v
references, and use it for the movXX patterns in my md?  Or, given that this
is likely to be the most common case and perhaps the only one I'm going to
care about, should I just define a pattern that matches the (set:SI
(zero_extend:SI (mem:QI))) insn directly?  Or how about the dodgy hacks that
temporarily reenable volatile_ok and then clear it again after calling the
recognizer?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Ian Lance Taylor]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Looking at it, this seems to be quite deliberate: combine_instructions()
> calls init_recog_no_volatile() before it runs the combine pass and
> init_recog() afterward.  I haven't delved into the morass of machine-generated
> loveliness that is insn-recog.c, but by modifying recog_for_combine() to try
> calling recog() twice, once with volatiles disabled, and once with them
> enabled, I've been able to determine that that's definitely the cause that
> prevents the volatile loads from being combined with the zero_extend
> operations.

When gcc sees a volatile memory reference, it has to make sure that it
dereferences the memory exactly as described in the source code.  But
it's easy for combine to combine two instructions which dereference
memory into one.  So combine simply disables combining instructions
which use volatile memory references.

>   What's a decent solution here?  Should I come up with a new version of
> general_operand, call it general_or_volatile_operand, that would accept mem/v
> references, and use it for the movXX patterns in my md?  Or, given that this
> is likely to be the most common case and perhaps the only one I'm going to
> care about, should I just define a pattern that matches the (set:SI
> (zero_extend:SI (mem:QI))) insn directly?  Or how about the dodgy hacks that
> temporarily reenable volatile_ok and then clear it again after calling the
> recognizer?

In principle the combiner could make sure that the same number and
type of volatile memory references occur both before and after the
combination, and reject it if not.

Ian

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Earnshaw]

On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:

> 
> In principle the combiner could make sure that the same number and
> type of volatile memory references occur both before and after the
> combination, and reject it if not.

It would also have to ensure that the volatile memory operation wasn't
moved across any other 'relevant' (for some suitable definition of
relevant) memory operation (combine can cause limited re-ordering of
load operations, for example).

R.

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Dave Korn]

Richard Earnshaw wrote:
> On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
> 
>> 
>> In principle the combiner could make sure that the same number and
>> type of volatile memory references occur both before and after the
>> combination, and reject it if not.
> 
> It would also have to ensure that the volatile memory operation wasn't
> moved across any other 'relevant' (for some suitable definition of
> relevant) memory operation (combine can cause limited re-ordering of
> load operations, for example).
> 
> R.


  Hmm, I think I see.  Well, that should be a fairly easy thing to ensure in
the case where we're combining two consecutive insns!  :-)

  I was going to special case the load-byte/zero_extend pair that I've been
particularly targeting, but now ISTM that I could perhaps be more general:
would I be right to think that if 

 - recog_for_combine fails initially, but succeeds when you set volatile_ok
and try again, 

      ... and ...

 - the insns in question are two consecutive insns (this is simpler than
testing every intervening insn to see if it has a 'relevant' mem ref; a
slightly more complex and less conservative test would be to test every
intervening insn and just see if there were _any_ mem refs rather than none at
all),

      ... and ...

 - there is only one mem ref in the two input insns and one in the combined
new pattern and that mem ref has the same mode (because that's simpler than
enumerating all the mem refs and recording their modes and worrying about
which order the various operands might be accessed in if the insns are
combined)

  ... then it's bound to be safe to let them combine?

  BTW, I found this comment from try_combine rather confusing:

  /* We come here when we are replacing a destination in I2 with the
     destination of I3.  */
 validate_replacement:

...since whenever the code comes here in _my_ case, I find that what's
happening is that a source in I3 (which matches the dest of I2) is being
replaced by the source of I2.  Is the comment just confusingly worded, or is
my understanding of what's happening here actually back-to-front in some way?




    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Earnshaw]

On Tue, 2005-11-22 at 15:33, Dave Korn wrote:
> Richard Earnshaw wrote:
> > On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
> > 
> >> 
> >> In principle the combiner could make sure that the same number and
> >> type of volatile memory references occur both before and after the
> >> combination, and reject it if not.
> > 
> > It would also have to ensure that the volatile memory operation wasn't
> > moved across any other 'relevant' (for some suitable definition of
> > relevant) memory operation (combine can cause limited re-ordering of
> > load operations, for example).
> > 
> > R.
> 
> 
>   Hmm, I think I see.  Well, that should be a fairly easy thing to ensure in
> the case where we're combining two consecutive insns!  :-)

I think that is probably unreasonably restrictive.

AFAICT it is probably safe to do the combination provided (in addition
to the normal restrictions on combine) that:

1) Not more than one volatile memory ref appears in the insns being
considered (i1 i2 i3) (we can't guarantee ordering in that case)
2) A volatile load isn't moved across any other volatile load or store
3) A volatile load isn't moved across any store that may alias (though
I'd expect that to be volatile if there's a real risk of aliasning, so
maybe we could have another dimension in the 'may-alias' test here).
3) The volatile load isn't moved across any insn containing
unspec_volatile.
4) The act of combining doesn't change the mode of the access to memory
(it may not be valid to access a subreg of a volatile SImode object
using QImode, for example).

There may, of course, be other restrictions that I haven't thought of...
:-)

Of these, perhaps the hardest to test is the last one, since now all the
simplification rules that we have will need checking for validity
(unless we can do some final check after substitution has been
completed).

R.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Richard Earnshaw wrote:

> AFAICT it is probably safe to do the combination provided (in addition
> to the normal restrictions on combine) that:

I think this is a bad idea in practice, since volatile will be used
to describe memory mapped devices, and combining can completely
mess up the access. Yes, it is probably conforming, but it is
simply not a good idea to do this, and the gain is too small.

Accidentally on the list....

[Eric J. Goforth]

Hi all;

I misunderstood what this list was for and ended up on it.  No 
instructions on the messages on how to get off and I don't' remember 
where I went to get on.. Can someone point me?  Thanks.

Eric

Re: Accidentally on the list....

[Gerald Pfeifer]

On Wed, 23 Nov 2005, Eric J. Goforth wrote:
> I misunderstood what this list was for and ended up on it.  No 
> instructions on the messages on how to get off and I don't' remember 
> where I went to get on.. Can someone point me?  Thanks.

Every message on this list carries the following headers:

  List-Unsubscribe: <mailto:gcc-unsubscribe-egoforth=fedora.goforthtech.com@gcc.gnu.org>
  List-Archive: <http://gcc.gnu.org/ml/gcc/>
  List-Post: <mailto:gcc@gcc.gnu.org>
  List-Help: <http://gcc.gnu.org/ml/>

Please follow the instructions at the List-Help URL or the 
List-Unsubscribe URL.

Gerald

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote:
> 3) A volatile load isn't moved across any store that may alias (though
> I'd expect that to be volatile if there's a real risk of aliasning, so
> maybe we could have another dimension in the 'may-alias' test here).

?  Is this just a restatement of the general rule that one cannot  
move a load across a store that may alias?  If so, we don't need to  
list it here, as it comes under the normal rules of what one may not  
do, and sense we don't relist all of them, there isn't any point in  
listing any of them.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 22, 2005, at 8:10 AM, Robert Dewar wrote:
> I think this is a bad idea in practice, since volatile will be used
> to describe memory mapped devices, and combining can completely
> mess up the access.

Only if one missed a restriction.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Earnshaw]

On Sun, 2005-11-27 at 03:14, Mike Stump wrote:
> On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote:
> > 3) A volatile load isn't moved across any store that may alias (though
> > I'd expect that to be volatile if there's a real risk of aliasning, so
> > maybe we could have another dimension in the 'may-alias' test here).
> 
> ?  Is this just a restatement of the general rule that one cannot  
> move a load across a store that may alias?  If so, we don't need to  
> list it here, as it comes under the normal rules of what one may not  
> do, and sense we don't relist all of them, there isn't any point in  
> listing any of them.

Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access? 
Logic would suggest that a program is unpredictable if written in such a
way that permits such aliases to exist, since it would mean a location
is being accessed in both non-volatile and volatile manner.

R.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Richard Earnshaw wrote:

> Possibly, but I think the more interesting observation is listed in
> parenthesis: Can a volatile access ever alias a non-volatile access?

I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.

> Logic would suggest that a program is unpredictable if written in such a
> way that permits such aliases to exist, since it would mean a location
> is being accessed in both non-volatile and volatile manner.

Exactly!

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Paolo Bonzini]

Robert Dewar wrote:
> Richard Earnshaw wrote:
> 
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
> 
> I think the answer is no, Certainly Ada has compile time rules
> carefully written to make this impossible.

Usually I try to avoid the realm of "hypotetical targets" and 
hypotetical optimizations, but I can imagine a target where one bit of a 
register needs to be accessed in a volatile way and the others need not.

Then, I don't know if it would be legal to optimize

   struct r {
     unsigned int x : 7;
     volatile unsigned int y : 1;
   };

   struct r my_reg;

So that my_reg.x is accessed with a non-volatile mem, and my_reg.y is 
accessed with a volatile one.  Would such an optimization be possible 
within the Ada compile-time rules?

Paolo

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
> Possibly, but I think the more interesting observation is listed in
> parenthesis: Can a volatile access ever alias a non-volatile access?
> Logic would suggest that a program is unpredictable if written in  
> such a
> way that permits such aliases to exist, since it would mean a location
> is being accessed in both non-volatile and volatile manner.

I think this is uninteresting, as I'd presume that it is valid, and  
the user really wanted to do it (the below is pseudo code, no, really):

int i[4096];

void foo() {
     i[0] = 0;
     mmap (... &i[0], ...);
     (*(volatile int *)&i[0]) = 1;
}

Anyway, why it is uninteresting is, the normal rules say they alias,  
so they alias.  And for people that just want to quote the standard,  
don't bother, let me:

        [#5] If an attempt is made to modify an object defined  with
        a  const-qualified  type  through use of an lvalue with non-
        const-qualified type, the  behavior  is  undefined.   If  an
        attempt  is  made  to  refer  to  an  object  defined with a
        volatile-qualified type through use of an lvalue  with  non-
        volatile-qualified type, the behavior is undefined.102)

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
>
> I think the answer is no, Certainly Ada has compile time rules
> carefully written to make this impossible.

gcc is not just an Ada compiler.  Clearly, the answer has to be yes  
to support GNU C.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Andrew Pinski]

> 
> On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
> >> Possibly, but I think the more interesting observation is listed in
> >> parenthesis: Can a volatile access ever alias a non-volatile access?
> >
> > I think the answer is no, Certainly Ada has compile time rules
> > carefully written to make this impossible.
> 
> gcc is not just an Ada compiler.  Clearly, the answer has to be yes  
> to support GNU C.

While it is true that GCC is not just an Ada compiler but I think we should
follow a sane set of rules for GNU C which might mean following Ada's rules
for this case.

What is GNU C if it is not well documented?

-- Pinski

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
> What is GNU C if it is not well documented?

:-)


^L

Useful.

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Dave Korn]

Mike Stump wrote:
> On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
>> Logic would suggest that a program is unpredictable if written in such a
>> way that permits such aliases to exist, since it would mean a location
>> is being accessed in both non-volatile and volatile manner.
> 
> I think this is uninteresting, as I'd presume that it is valid, and
> the user really wanted to do it (the below is pseudo code, no, really):
> 
> int i[4096];
> 
> void foo() {
>      i[0] = 0;
>      mmap (... &i[0], ...);
>      (*(volatile int *)&i[0]) = 1;
> }
> 
> Anyway, why it is uninteresting is, the normal rules say they alias,
> so they alias.  And for people that just want to quote the standard,
> don't bother, let me:
> 
>         [#5] If an attempt is made to modify an object defined  with
>         a  const-qualified  type  through use of an lvalue with non-
>         const-qualified type, the  behavior  is  undefined.   If  an
>         attempt  is  made  to  refer  to  an  object  defined with a
>         volatile-qualified type through use of an lvalue  with  non-
>         volatile-qualified type, the behavior is undefined.102)


  :)  I seem to remember this case having come up in a very long thread
earlier this year, when we were discussing whether what was relevant was the
actual type and quals of the object being accessed, or the type and quals of
the decl/pointer through which it was being accessed.

  And all of this is quite a way off from where I came in.  We're worrying
about moving accesses past each other, and aliasing, and so on.  All I ever
wanted to do was combine a *single* volatile access with an
immediately-consecutive ALU operation on the result of that volatile access.

  BTW, I never did manage to find the patches you referred to in your postings
from summer 2000.  Googling for "mike stump volatile_ok" just kept on finding
me the post where you were advising someone to find your patches by searching
for your name and volatile_ok.  Kinda recursive, that.... do you still have a
pointer to them?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
> While it is true that GCC is not just an Ada compiler but I think  
> we should
> follow a sane set of rules for GNU C which might mean following  
> Ada's rules
> for this case.

Because GNU C doesn't have rules carefully written to make this  
impossible, our rules are carefully written to make it possible.  If  
you want to code in Ada, feel free.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Andrew Pinski]

> 
> On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
> > While it is true that GCC is not just an Ada compiler but I think  
> > we should
> > follow a sane set of rules for GNU C which might mean following  
> > Ada's rules
> > for this case.
> 
> Because GNU C doesn't have rules carefully written to make this  
> impossible, our rules are carefully written to make it possible.  If  
> you want to code in Ada, feel free.

Huh? they are not carefully written at all.  This is why I said what
is GNU C?  Again the language is not written out so it means anything.

If poeple want something defined the way they like it, please write some
documentation that way and post a patch.  I could care which way it goes
except right now, we can do anything because it is not that well written
(well it is undocuemented).

-- Pinski

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 9:41 AM, Andrew Pinski wrote:
> Huh? they are not carefully written at all.  This is why I said what
> is GNU C?  Again the language is not written out so it means anything.

So then clearly, since it means anything, we can change gcc to accept  
pascal instead of C?  Right?  This is absurd.

> If poeple want something defined the way they like it, please write  
> some
> documentation that way and post a patch.  I could care which way it  
> goes
> except right now, we can do anything because it is not that well  
> written
> (well it is undocuemented).

I disagree.  For example, there is behavior mandated by the Standard  
for C, such as this, that, reasonably, I think we have to follow.   
You can argue that we don't have to follow the standard but I'm not  
just going to listen to you.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Joe Buck]

On Mon, Nov 28, 2005 at 09:53:31AM -0800, Mike Stump wrote:
> On Nov 28, 2005, at 9:41 AM, Andrew Pinski wrote:
> >Huh? they are not carefully written at all.  This is why I said what
> >is GNU C?  Again the language is not written out so it means anything.
> 
> So then clearly, since it means anything, we can change gcc to accept  
> pascal instead of C?  Right?  This is absurd.

Mike, you wrote "GNU C", not "ISO C".  There's no spec for the former.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 9:29 AM, Dave Korn wrote:
>   BTW, I never did manage to find the patches you referred to in  
> your postings
> from summer 2000.  Googling for "mike stump volatile_ok" just kept  
> on finding
> me the post where you were advising someone to find your patches by  
> searching
> for your name and volatile_ok.  Kinda recursive, that.... do you  
> still have a
> pointer to them?

As background for others,

http://gcc.gnu.org/ml/gcc-bugs/1999-12n/msg00801.html

has an example of why one would want to do this.

Anyway, not rocket science:

Doing diffs in .:
--- ./recog.c.~1~       2005-10-28 10:40:18.000000000 -0700
+++ ./recog.c   2005-11-28 10:10:31.000000000 -0800
@@ -956,9 +956,6 @@ general_operand (rtx op, enum machine_mo
      {
        rtx y = XEXP (op, 0);

-      if (! volatile_ok && MEM_VOLATILE_P (op))
-       return 0;
-
        /* Use the mem's mode, since it will be reloaded thus.  */
        if (memory_address_p (GET_MODE (op), y))
         return 1;
--------------

Good for testing, but a real patch would have to:

http://gcc.gnu.org/ml/gcc/2001-11/msg00398.html

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 10:08 AM, Joe Buck wrote:
>> So then clearly, since it means anything, we can change gcc to accept
>> pascal instead of C?  Right?  This is absurd.
>
> Mike, you wrote "GNU C", not "ISO C".  There's no spec for the former.

He said we can do anything, this is untrue.  I rail against the  
casual use of the word because it misleads others into believing it,  
and then proposing patches that do anything they want, and yet make  
gcc worse.  I realize there that we have no documentation person that  
writes down everything religiously and that from time to time, people  
that should write documentation, don't.  I'm just as guilty (or more  
so) as everyone else.  Realize, some consider that just a simple  
documentation bug, not an opportunity to go messing with a fine  
compiler.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Mike Stump wrote:

> gcc is not just an Ada compiler.  Clearly, the answer has to be yes  to 
> support GNU C.

Right, I agree, I was answering whether this can ever be done
legitimately, and the answer is really no, it is undefined in
C, and if you manage to do it in Ada, which you can if you
really try by unchecked conversion of pointer types etc,
then it is erroneous there too.

So I don't see that the compiler has to allow for this in
any explicit manner, given that its effect is undefined in
C.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Mike Stump wrote:

> I disagree.  For example, there is behavior mandated by the Standard  
> for C, such as this, that, reasonably, I think we have to follow.   You 
> can argue that we don't have to follow the standard but I'm not  just 
> going to listen to you.

Hmm, I guess I misread the standard, I thought it said the effect
was undefined.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 11:05 AM, Robert Dewar wrote:
> Right, I agree, I was answering whether this can ever be done
> legitimately, and the answer is really no, it is undefined in
> C

It is not.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 11:12 AM, Robert Dewar wrote:
> Mike Stump wrote:
>> I disagree.  For example, there is behavior mandated by the  
>> Standard  for C, such as this, that, reasonably, I think we have  
>> to follow.   You can argue that we don't have to follow the  
>> standard but I'm not  just going to listen to you.
>
> Hmm, I guess I misread the standard, I thought it said the effect
> was undefined.

Only in one direction does the standard make it undefined, as I  
quoted.  I know why they do this, and I am arguing that that latitude  
should not be used to try and `optimize' things to make them behave  
differently (such as calling abort for example) in the presence of  
volatile.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Mike Stump wrote:

> Only in one direction does the standard make it undefined, as I  
> quoted.  I know why they do this, and I am arguing that that latitude  
> should not be used to try and `optimize' things to make them behave  
> differently (such as calling abort for example) in the presence of  
> volatile.

There is no point in deliberately creating bad behavior, but on the
other hand, there is no basis for suppressing a generally useful
optimization to guarantee someones idea of a definition of undefined.
I do agree that if

a) everyone agrees on what the "sensible" definition is
b) the optimization is not valuable

then it is better to behave as expected.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

[...]

| I do agree that if
| 
| a) everyone agrees on what the "sensible" definition is

We do have a standard definied beahviour.

| b) the optimization is not valuable

for those people who don't care about the standard semantics, there is
always an option to provide a compiler switch.

-- Gaby

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Gabriel Dos Reis wrote:

> | I do agree that if
> | 
> | a) everyone agrees on what the "sensible" definition is
> 
> We do have a standard definied beahviour.

in one case, and of course we must adhere to this,
but not in the other case
> 
> | b) the optimization is not valuable
> 
> for those people who don't care about the standard semantics, there is
> always an option to provide a compiler switch.

I am talking only about the undefined case

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Laurent GUERBY]

On Mon, 2005-11-28 at 14:10 +0100, Paolo Bonzini wrote:
> Then, I don't know if it would be legal to optimize
> 
>    struct r {
>      unsigned int x : 7;
>      volatile unsigned int y : 1;
>    };
> 
>    struct r my_reg;
> 
> So that my_reg.x is accessed with a non-volatile mem, and my_reg.y is 
> accessed with a volatile one.  Would such an optimization be possible 
> within the Ada compile-time rules?

procedure P is

   type T7 is mod 2**7;
   type T1 is mod 2;
   pragma Volatile (T1);

   type R is record
      X : T7;
      Y : T1;
   end record;
   for R'Size use 8;
   for R'Alignment use 1;
   for R use record
      X at 0 range  0 ..  6;
      Y at 0 range  7 ..  7;
   end record;

   Z : R;
   A : T7;
   B : T1;
begin
   Z.X := 127;
   Z.Y := 1;
   A := Z.X;
   B := Z.Y;
end P;

trunk gcc -O2 -S p.adb on x86-linux gives:

_ada_p:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $16, %esp
        movb    $1, -1(%ebp)
        leave
        ret

My understanding is that B := Z.Y implied memory read should not be
optimized away since it is a volatile read and thus an external effect,
so this looks like a bug to me. (If this is not supported, GNAT should
fail at compile time.)

Z.X write and read are correctly optimized away: non volatile
read and write have no external effects here.

Laurent

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Laurent GUERBY wrote:
> On Mon, 2005-11-28 at 14:10 +0100, Paolo Bonzini wrote:
> 
>>Then, I don't know if it would be legal to optimize
>>
>>   struct r {
>>     unsigned int x : 7;
>>     volatile unsigned int y : 1;
>>   };
>>
>>   struct r my_reg;
>>
>>So that my_reg.x is accessed with a non-volatile mem, and my_reg.y is 
>>accessed with a volatile one.  Would such an optimization be possible 
>>within the Ada compile-time rules?

There is no analogous declaration possible in Ada.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Andrew Pinski]

> 
> On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
> > I was, there was no where in I was saying we should break ISO standard
> 
> The effect of following Ada's rules:
> 
> > While it is true that GCC is not just an Ada compiler but I think  
> > we should
> > follow a sane set of rules for GNU C which might mean following  
> > Ada's rules
> > for this case.
> 
> would depart from ISO mandated behavior.

I said might, I never said we will follow the Ada rules.

Please read my email as requesting for more documention on this
matter rather than requesting we change to the wrong behavior.

And what is sane rules depends on what people think are sane.

-- Pinski

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
> I was, there was no where in I was saying we should break ISO standard

The effect of following Ada's rules:

> While it is true that GCC is not just an Ada compiler but I think  
> we should
> follow a sane set of rules for GNU C which might mean following  
> Ada's rules
> for this case.

would depart from ISO mandated behavior.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Andrew Pinski]

> 
> On Nov 28, 2005, at 10:55 AM, Richard Kenner wrote:
> > It's not that simple and I suspect you know it.
> 
> Yes, this is all fine and very well, but do you realize that Andrew  
> wanted to break gcc behavior as mandated by the ISO standard?  This  
> is very, very simple.  The answer is no.  I'm not budging on this,  
> really.

I was, there was no where in I was saying we should break ISO standard but
I was saying that GNU C needs to better defined and if in that point, making
it clearer that GNU C is superset of ISO C, that is the best way of doing it.

Making what volatile means to GNU C clearer is no different than making
saying in the documention what volatile means to the ISO C standard.

-- Pinski

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 10:55 AM, Richard Kenner wrote:
> It's not that simple and I suspect you know it.

Yes, this is all fine and very well, but do you realize that Andrew  
wanted to break gcc behavior as mandated by the ISO standard?  This  
is very, very simple.  The answer is no.  I'm not budging on this,  
really.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Kenner]

    He said we can do anything, this is untrue.  I rail against the casual
    use of the word because it misleads others into believing it, and then
    proposing patches that do anything they want, and yet make gcc worse.
    I realize there that we have no documentation person that writes down
    everything religiously and that from time to time, people that should
    write documentation, don't.  I'm just as guilty (or more so) as
    everyone else.  Realize, some consider that just a simple
    documentation bug, not an opportunity to go messing with a fine compiler.

It's not that simple and I suspect you know it.  The things that aren't
written down are the "contract" between the programmer and the compiler
about what the latter is guaranteeing to the former.  It's nice to say
that a compiler won't ever make a change that won't break *any* program,
but that's impossible.  Even the slightest change can "break" a program
that relies on an uninitialized variable, for example.  Obviously, we
understand that's permissible because such a program is "not correct"
or "erroneous".  But the problem in extending that doctrine is that we
have to know which programs are erroneous and when there's no precise
documentation of the language in which they're written (GNU C),
there's no way to say with certainty whether a program is or not.
So there's no way to know whether the set of programs that a given
change will break consists of just erroneous programs.  One can take
the very conservative approach of avoiding that problem by not making
*any* changes that could conceivably break a program, but that would mean
making no progress on improving a "fine compiler".

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Mike Stump]

On Nov 28, 2005, at 9:33 AM, Richard Kenner wrote:
> And where is the standard for the language known as "GNU C"?

You can obtain the ISO definition for C from ISO:

        61)The intent of this list is to specify those circumstances
           in which an object may or may not be aliased.

          [#7] An object shall have its stored value accessed only  by
        an lvalue expression that has one of the following types:61)

          -- a  type  compatible  with  the  effective  type  of the
             object,

          -- a qualified version  of  a  type  compatible  with  the
             effective type of the object,

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Kenner]

    >> Possibly, but I think the more interesting observation is listed in
    >> parenthesis: Can a volatile access ever alias a non-volatile access?
    >
    > I think the answer is no, Certainly Ada has compile time rules
    > carefully written to make this impossible.

    gcc is not just an Ada compiler.  Clearly, the answer has to be yes  
    to support GNU C.

And where is the standard for the language known as "GNU C"?  One of the
major problems with the GNU C extensions has been that they were done in an
era where people weren't as precise as they are today regarding language
definition and the interactions of features with each other and with
optimizations.

Obviously, Robert was giving Ada as an example of a language that *does*
precisely give the answers to these questions, unlikely GNU C.  Another
interesting datapoint is clearly what the current C and C++ standards say on
the matter.  However, despite the legacy code issue, I wouldn't put too much
import on the relatively informal definition of "GNU C".

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Richard Earnshaw wrote:

> Consider a non-load/store machine that has a floating-point operation that 
> can add a value in memory to another register:
> 
> 	fadd Rd, Rs, (mem)  // Rd = Rs + (mem)
> 
> Now if (mem) is volatile and the value returned is a signalling NaN then
> the trap handler has no way to recover that value except by
> dereferencing (mem) again.  That means we access (mem) twice.
> 
> Or consider any type of 3-operand instruction where both source operands
> come from memory.  If the first access is volatile and the second not
> (but it page-faults) then, unless the machine has some way to cache the
> first access, it will have to be repeated when the page fault handler
> returns.

The above cases simply do not occur on any common machine, so perhaps
you would have to do strange things in those cases, but nothing like
the drastic generalization you first gave. Generally even on machines
with these kind of instructions it is better to do separate loads
anyway.
> 
> Finally, but probably less likely, consider a machine instruction that
> can read multiple values from memory (ARM has one -- ldm).  If an
> address in the list is volatile and the list crosses a page boundary,
> the instruction may trap part way through execution.  In that case the
> OS may have to unwind part of the instruction and retry it -- it can't
> safely do that if there is a volatile access in the list.

Well don't use this instruction if one of the addresses is volatile.
That seems right in any case (it seems wrong to do other than generate
a single load/store for volatile anyway, this seems like improper
combining).
> 
> R.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Earnshaw]

On Wed, 2005-11-23 at 11:41, Robert Dewar wrote:
> Richard Earnshaw wrote:
> 
> > This restriction rules out, for example, using a volatile value as an
> > input in many floating point operations (since the operations may trap
> > depending on the values read).
> 
> I don't see this at all. If you have a volatile variable that traps
> in this situation, then that's just fine, you get the trap. The trap
> cannot occur unless the program is wandering into undefined areas in
> any case. Please give an exact scenario here, and explain why you
> think the standard or useful pragmatic considerations demand the
> treatment you suggest above.
> > 
> > R.

Consider a non-load/store machine that has a floating-point operation that 
can add a value in memory to another register:

	fadd Rd, Rs, (mem)  // Rd = Rs + (mem)

Now if (mem) is volatile and the value returned is a signalling NaN then
the trap handler has no way to recover that value except by
dereferencing (mem) again.  That means we access (mem) twice.

Or consider any type of 3-operand instruction where both source operands
come from memory.  If the first access is volatile and the second not
(but it page-faults) then, unless the machine has some way to cache the
first access, it will have to be repeated when the page fault handler
returns.

Finally, but probably less likely, consider a machine instruction that
can read multiple values from memory (ARM has one -- ldm).  If an
address in the list is volatile and the list crosses a page boundary,
the instruction may trap part way through execution.  In that case the
OS may have to unwind part of the instruction and retry it -- it can't
safely do that if there is a volatile access in the list.

R.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Richard Earnshaw wrote:

> This restriction rules out, for example, using a volatile value as an
> input in many floating point operations (since the operations may trap
> depending on the values read).

I don't see this at all. If you have a volatile variable that traps
in this situation, then that's just fine, you get the trap. The trap
cannot occur unless the program is wandering into undefined areas in
any case. Please give an exact scenario here, and explain why you
think the standard or useful pragmatic considerations demand the
treatment you suggest above.
> 
> R.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Earnshaw]

On Tue, 2005-11-22 at 19:10, Robert Dewar wrote:
> Dave Korn wrote:
> > Robert Dewar wrote:
> > 
> 
> >   Isn't it pretty much implied by point 1, "Not more than one volatile memory
> > ref appears in the instructions being considered"?  
> 
> No, that allows a volatile reference to be combined with something else.
> I think this is a mistake, because people often think of volatile as
> guaranteeing what Ada would call an atomic access, one instruction
> accessing just the variable and nothing else.

If there are N volatile accesses in the sequence under consideration,
there must be exactly N volatile accesses in the resulting combination
(the only thing I've missed in my list is to say that the volatile
reference can't be eliminated -- I've already restricted N to 1, and
rule 4 already said that the mode of the access couldn't change).

There is, however, a further restriction that I thought of last night. 
This is very hard to maintain generally, and may therefore be a near
show-stopper:

5) The instruction must never need to be restarted after the volatile
access has been accepted by the memory system.

This restriction rules out, for example, using a volatile value as an
input in many floating point operations (since the operations may trap
depending on the values read).

R.

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Dave Korn]

Robert Dewar wrote:
> Dave Korn wrote:
>> Robert Dewar wrote:
>> 
> 
>>   Isn't it pretty much implied by point 1, "Not more than one volatile
>> memory ref appears in the instructions being considered"?
> 
> No, that allows a volatile reference to be combined with something else.

  Ah, I misunderstood you... when you said "you never combine volatile
references" I thought you meant "with each other"!

> I think this is a mistake, because people often think of volatile as
> guaranteeing what Ada would call an atomic access, one instruction
> accessing just the variable and nothing else.

  Well, yes, they do.  So do I, more-or-less!

  Remember, however, that in the particular case I was concerned with, we can
show that the second insn is actually a no-op (because we have LOAD_EXTEND_OP
telling us so), and the only reason I want them combined is so that the second
insn can be entirely eliminated.  So I think it's reasonable to fold a
volatile mem-ref into what amounts to a nop-move.

  The thing is that the load-byte insn on my target clears the upper 24 bits
of the register, and gcc takes advantage of that when (e.g.) you load bytes
into registers prior to doing a comparison.  But if those bytes are loaded
through volatile pointers, it needlessly adds an AND with 0xFF immediate after
the load.  This is a common enough situation in our application to be worth
fixing in the compiler.

  So, I think I'm going to go with my current approach, which is:

- If the insn isn't recognized, but allowing volatile_ok causes it to be
recognized
- and the insns are consecutive SETs
- and the SET_SRC for i2 is a mem ref and the SET_DEST is a reg
- and the SET_SRC for i3 is a zero_extend or sign_extend
- and the operand of the zero or sign extend in i3 matches either the SET_DEST
of i2 or the SET_SRC of i2 [*] 
- and LOAD_EXTEND_OP for the mem ref's mode matches the code of the SET_SRC in
i3
- and the reg from the SET_DEST of i2 has a REG_DEAD note on i3

then it's OK to combine.  Unless of course someone points out some major flaw
in my reasoning.

  Note the slightly funny test at [*].  That's because i3 has already been
partially combined/simplified at the point in try_combine
(validate_replacement:) where I'll be doing this test.  I want to discriminate
from the case where these are actually two entirely separate references to the
same memory location, one of which just happens to be inside a zero/sign
extend.

  This should be specific enough to catch my volatile byte loads without
borking any other construct, I hope.  At any rate, if there's a loophole in
that set of rules I can't see it.  I had hoped to make a more general
improvement to combine, though.  I guess that any time I have a volatile load
followed by an ALU-style op that uses the dest of that load and leaves the
load's dest reg_dead, I could in theory combine it validly - but there's no
point doing so except in the case where LOAD_EXTEND_OP (or any other reason)
means that part of the resulting construction can be eliminated, rather than
just splitting the thing back to separate insns sometime in final code
generation.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Dave Korn wrote:
> Robert Dewar wrote:
> 

>   Isn't it pretty much implied by point 1, "Not more than one volatile memory
> ref appears in the instructions being considered"?  

No, that allows a volatile reference to be combined with something else.
I think this is a mistake, because people often think of volatile as
guaranteeing what Ada would call an atomic access, one instruction
accessing just the variable and nothing else.

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Dave Korn]

Robert Dewar wrote:
> Richard Kenner wrote:
> 
>> The issue is that we currently don't combine if volatile is anywhere in
>> sight, whether or not we'd be affecting that access. Just because you
>> have something volatile on the LHS doesn't mean we can't combine into
>> the RHS.  A good example are addressing modes: if we have a MEM->MEM
>> copy with one side volatile, doing anything inside the addressing
>> computation of either (even the volatile one) is perfectly safe.
> 
> OK, in that case you have to add to the list of restrictions that you
> never combine volatile references. 

  It's because of the complexity of thinking through all these issues that my
first suggestion was so conservative.

>I did not see that in the list.

  Isn't it pretty much implied by point 1, "Not more than one volatile memory
ref appears in the instructions being considered"?  

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Robert Dewar]

Richard Kenner wrote:

> The issue is that we currently don't combine if volatile is anywhere in
> sight, whether or not we'd be affecting that access. Just because you have
> something volatile on the LHS doesn't mean we can't combine into the RHS.  A
> good example are addressing modes: if we have a MEM->MEM copy with one side
> volatile, doing anything inside the addressing computation of either (even
> the volatile one) is perfectly safe.

OK, in that case you have to add to the list of restrictions that you
never combine volatile references. I did not see that in the list.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

[Richard Kenner]

    > AFAICT it is probably safe to do the combination provided (in addition
    > to the normal restrictions on combine) that:

    I think this is a bad idea in practice, since volatile will be used
    to describe memory mapped devices, and combining can completely
    mess up the access. Yes, it is probably conforming, but it is
    simply not a good idea to do this, and the gain is too small.

The issue is that we currently don't combine if volatile is anywhere in
sight, whether or not we'd be affecting that access. Just because you have
something volatile on the LHS doesn't mean we can't combine into the RHS.  A
good example are addressing modes: if we have a MEM->MEM copy with one side
volatile, doing anything inside the addressing computation of either (even
the volatile one) is perfectly safe.

I do agree, of course, that the gain here is small, but we do lots of things
in GCC with small gains ...