This is the mail archive of the gcc-patches@gcc.gnu.org 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: Volatile MEMs in statement expressions and functions inlinedastrees


(sorry for direct email, but my mail relay is rejected by gnu.org)
[relayed to gcc-patches -aoliva]

Please let me refine my earlier expansion, such that an lvalue expression
returns "the value stored" if referenced, and let lt/rt/tt represent
lvalue/rvalue/target-lvalue-type casts, and assume l/rvalue references are
appropriately implicitly de-referenced, which may be optimized such that:
- all volatile rv (rvalue) operand references are load-enforced,
- all volatile lv (lvalue) target references are store-enforced.
- each explicit/implicit volatile reference will yield one
  and only one corresponding load/store-enforced operation.

Where since a statement doesn't return a value, therefore doesn't imply a
root/terminating r/lvalue reference, therefore:

(lt)lv :: <null-expression/operation>

(lt)lv = rv :: lv = ((lt)tmp = rv, (lt)tmp)

Where an (rvalue) referenced expression does imply a value reference:

(tt)(rv) :: ((tt)tmp = rv, (tt)tmp)

(tt)(lv = rv) :: (lv = ((lt)tmp = rv, (lt)tmp), (tt)((lt)tmp))

Thereby:

q = (p = (x))

:: q = ((qt)tmp2 = (p = ((pt)tmp1 = x, (pt)tmp1), (qt)((pt)tmp1)), (qt)tmp2)

Yielding:
- logically (pt)tmp = x, p = (pt)tmp, q = (qt)((pt)tmp);
- one potentially volatile non-optimizable load: (pt)tmp = x;
- two potentially volatile non-optimizable stores: p = (pt)tmp, q =
(qt)((pt)temp);

q++ :: q = ((q) + 1) :: q = ( ((qt)tmp = q, (qt)tmp) + (qt)1 )

Yielding:
- logically (qt)tmp = q, q = ((qt)tmp + (qt)1);
- one potentially volatile non-optimizable load: (qt)tmp = q;
- one potentially volatile non-optimizable store: q = ((qt)tmp + (qt)1);

For functions, a return value implies an assignment to the function value,
otherwise no return value reference is implied, therefore:

ft f(){ q; ... } :: <null-expression/operation>(related to q;)

Yielding:
- logically no operations related to q;
- zero potentially volatile non-optimizable load/stores related to q;

ft f(){ ... temp = q; } :: (tt)temp = ((tt)tmp = q, (tt)tmp)

Yielding:
- logically (tt)tmp = q, temp = (tt)tmp;
- one potentially volatile non-optimizable load: (tt)tmp = q;
- zero potentially volatile non-optimizable stores related to q;

ft f(){ ... return q; } :: fv = ((ft)tmp = q, (ft)tmp)

Yielding:
- logically (ft)tmp = q, fv = (ft)tmp;
- one potentially volatile non-optimizable load: (ft)tmp = q;
- zero potentially volatile non-optimizable stores related to (return q);

and so on...

-paul-


> would suspect that:
> 
> rvalue :: (temp = rvalue, temp)
> 
> therefor:
> 
> lvalue = rvalue :: lvalue = (temp = rvalue, temp)
> 
> therefor:
> 
> q = p = x :: q = (p = (x)) :: q = (temp2 = (p = (temp1 = x, temp1)), temp2)
> 
> equivalent to:
> 
> q = p = x :: q = (p = (temp = x, temp), temp)
> 
> which may be optimized such that:
> - all volatile rvalue operand references are load-enforced,
> - all volatile lvalue operand targets are store-enforced.
> - each explicit or implied volatile reference will yield one
> and only one corresponding load/store-enforced operation.
> 
> yielding:
> - one potentially volatile non-optimizable load: temp = x;
> - two potentially volatile non-optimizable stores: p = temp, q = temp;
> 
> correspondingly:
> 
> q += p :: q = ((q) + (p)) :: q = ((temp1 = q, temp1) + (temp2 = p, temp2))
> 
> yielding:
> - two potentially volatile non-optimizable loads: temp1 = q, temp2 = p;
> - one potentially volatile non-optimizable store: q = (temp1 + temp2);
> 
> q++ :: q = ((q) + (1)) :: q = ((temp = q, temp) + 1)
> 
> yielding:
> - one potentially volatile non-optimizable load: temp = q;
> - one potentially volatile non-optimizable store: q = (temp + 1)
> 
> q :: <null-lvalue-operation>
> 
> - zero potentially volatile non-optimizable loads, stores, or side-effects;
> 
> and so forth...
> 
> -paul-


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