[Bug tree-optimization/18842] Weak optimization on global references

[Bug tree-optimization/18842] Weak optimization on global references

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-03-05 21:30 -------
(In reply to comment #2)
> This is not a bug.  You need IPA to figure out that y is never changed.  For 
> example: 
>  
> int x, &y = x, z; 
> int bar() { y = z; } 

This actually does:
*y = z; and not y = &z;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[felix dot nawothnig at t-online dot de]

------- Comment #8 from felix dot nawothnig at t-online dot de  2006-07-16 14:23 -------
Don't know much about GCC internals but shouldn't this be a very trivial
enhancement? I know that this is FOSS so not to annoy anyone, just wondering
why it's still open after >1 year.

(In case someone is wondering why I care - this is the only one thing where
it's still faster to use macros instead of inline functions & references and
this access is a huge bottleneck in my application)


-- 

felix dot nawothnig at t-online dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |felix dot nawothnig at t-
                   |                            |online dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2006-07-16 20:36 -------
You could try it yourself.  But - do you have a testcase that shows how macros
and inline functions come into play here?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2009-04-22 22:02 -------
Fixed in 4.4.0 and above.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug c++/18842] New: Weak optimization on global references

[felix dot nawothnig at t-online dot de]

int x, &y = x;
int main() { y = 42; }

produces

x:
        .zero   4
...
y:
        .long   x
...
        movl    y, %eax
        movl    $42, (%eax)

Since a non-arg reference is always (?) constant it would be safe to omit

        movl    $42, x

-- 
           Summary: Weak optimization on global references
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: felix dot nawothnig at t-online dot de
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-05 15:14 -------
Consider these two TUs:
extern int *y, x, z;
int foo();
extern "C" void abort();
int main()
{
  foo();
  if (*y!=42)
   abort();
  if (y!=&x)
   abort();
  y = &z;
  foo ();
  if (*y!=42)
   abort();
  if (y!=&z)
   abort();
  return 0;
}
-----
int x, &y = x, z; 
int foo() { y = 42; } 
-----
Now I think the above is invalid C++ but we don't have to diagnostic since the standard allows us not 
to but since the standard allows the correct way, we can optimizate global references now.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |tree-optimization
     Ever Confirmed|                            |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-05 15:14:15
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[felix dot nawothnig at t-online dot de]

------- Additional Comments From felix dot nawothnig at t-online dot de  2004-12-05 19:10 -------
Diagnostics? Both files are 100% valid C++ - but since the C++ standard doesn't
enforce implementation of references as pointers they cause ABI-defined (?)
behaviour at/after linkage, just as...

extern int x;
void main() { foo(); assert(x == 5); }
---
float x;
void foo() { x = 5; }

...isn't guaranteed to "work" either. (but is still valid C)

Reading the reference over a pointer would still work because we can't remove
the reference itself from the object since someone might do "extern int &y;" in
another file - but it's evil. (non-portable)

*And* they are guaranteed to be const by the standard.

So, yes, safe to optimize. I think. :)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842

[Bug tree-optimization/18842] Weak optimization on global references

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-05 19:15 -------
(In reply to comment #5)
> Diagnostics? Both files are 100% valid C++ - but since the C++ standard doesn't
> enforce implementation of references as pointers they cause ABI-defined (?)
> behaviour at/after linkage, just as...

Yes both files are valid C++ but when you link them together they become invalid C++ and yes
the C++ defines this as invalid with no diagnostic required.  In fact your example is also invalid C++
but since the standard says we don't have to provide diagnostic as it is a hard problem to actually 
provide the diagnostic.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18842