public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change
@ 2021-01-05 22:09 tkoenig at gcc dot gnu.org
2021-01-05 22:10 ` [Bug tree-optimization/98552] " tkoenig at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-05 22:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Bug ID: 98552
Summary: Make more use of __builtin_undefined for assuring that
variables do not change
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
void foo (int *);
void bar (int n)
{
int i;
for (i=0; i<n; i++)
foo(&i);
}
void baz(int n)
{
int i, j;
for (i=0; i<n; i++)
{
j = i;
foo (&i);
if (j /= i)
__builtin_unreachable();
}
}
Assembly for bar and baz are identical, the loop is
.L9:
leaq 12(%rsp), %rdi
call foo
movl 12(%rsp), %eax
addl $1, %eax
movl %eax, 12(%rsp)
cmpl %ebx, %eax
jl .L9
In function bar, things are clear - the value of i has to be
reloaded from the stack, foo might have changed it.
However, this is not possible in baz. j cannot be changed, and the
__builtin_unreachable ensures that i has the same value before and
after the call to foo. It need not be reloaded from the stack.
(The reason why I'm submitting this is another way to approach PR 31593 -
the Fortran front end could annotate code like this to inform
the middle end that DO loops variables are, in fact, invariant).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
@ 2021-01-05 22:10 ` tkoenig at gcc dot gnu.org
2021-01-06 2:26 ` tobi at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-05 22:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |11.0
Keywords| |missed-optimization
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=31593
Severity|normal |enhancement
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
2021-01-05 22:10 ` [Bug tree-optimization/98552] " tkoenig at gcc dot gnu.org
@ 2021-01-06 2:26 ` tobi at gcc dot gnu.org
2021-01-06 8:04 ` tkoenig at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: tobi at gcc dot gnu.org @ 2021-01-06 2:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Tobias Schlüter <tobi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tobi at gcc dot gnu.org
--- Comment #1 from Tobias Schlüter <tobi at gcc dot gnu.org> ---
There's a typo in the example, /= instead of !=. Fixed example below:
I sprinkled const's all over foo's prototype and 'i' still gets reloaded so it
stands to reason that the compiler doesn't see the optimization opportunity.
======================
void foo (int *);
void bar (int n)
{
int i;
for (i=0; i<n; i++)
foo(&i);
}
void baz(int n)
{
int i, j;
for (i=0; i<n; i++)
{
j = i;
foo (&i);
if (j != i)
__builtin_unreachable();
}
}
======================
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
2021-01-05 22:10 ` [Bug tree-optimization/98552] " tkoenig at gcc dot gnu.org
2021-01-06 2:26 ` tobi at gcc dot gnu.org
@ 2021-01-06 8:04 ` tkoenig at gcc dot gnu.org
2021-01-06 8:08 ` tobi at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-06 8:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Tobias Schlüter from comment #1)
> There's a typo in the example, /= instead of !=. Fixed example below:
The disease of a Fortran programmer writing C, I guess :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
` (2 preceding siblings ...)
2021-01-06 8:04 ` tkoenig at gcc dot gnu.org
@ 2021-01-06 8:08 ` tobi at gcc dot gnu.org
2021-01-09 11:44 ` tkoenig at gcc dot gnu.org
2021-12-23 9:51 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: tobi at gcc dot gnu.org @ 2021-01-06 8:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #3 from Tobias Schlüter <tobi at gcc dot gnu.org> ---
Don't ask how long I'd been staring at the assembly in disbelief until I
figured out what had gone wrong :-)
In this particular case the problem can be addressed by passing &j into the
function instead of &i, so I wonder why the Fortran f.e. can't do that? One
possible problem is that if j's address escapes (in the sense that the compiler
assumes that subsequent function calls can do whatever to it), you'd need a new
fake memory location.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
` (3 preceding siblings ...)
2021-01-06 8:08 ` tobi at gcc dot gnu.org
@ 2021-01-09 11:44 ` tkoenig at gcc dot gnu.org
2021-12-23 9:51 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-09 11:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Yes, I think that translating a DO loop into something like
int i;
for (i=0; i<n; i++)
{
const int j = i;
/* Use j from here on where i is referenced. */
}
might solve a few of the issues in DO loop optimization.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
` (4 preceding siblings ...)
2021-01-09 11:44 ` tkoenig at gcc dot gnu.org
@ 2021-12-23 9:51 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-23 9:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-12-23
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-12-23 9:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-05 22:09 [Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change tkoenig at gcc dot gnu.org
2021-01-05 22:10 ` [Bug tree-optimization/98552] " tkoenig at gcc dot gnu.org
2021-01-06 2:26 ` tobi at gcc dot gnu.org
2021-01-06 8:04 ` tkoenig at gcc dot gnu.org
2021-01-06 8:08 ` tobi at gcc dot gnu.org
2021-01-09 11:44 ` tkoenig at gcc dot gnu.org
2021-12-23 9:51 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).