public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/59159] New: Need opaque pass-through as optimization barrier
@ 2013-11-17 11:41 glisse at gcc dot gnu.org
2013-11-17 15:31 ` [Bug c/59159] " joseph at codesourcery dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-11-17 11:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
Bug ID: 59159
Summary: Need opaque pass-through as optimization barrier
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
(category:c because I am asking for a built-in, but this is more about
middle/back-end)
Since gcc doesn't support FENV, I often need to insert optimization barriers in
my code that hide things from gcc optimizers, so it doesn't perform constant
propagation, or replace x*-y with -x*y, or move operations across fesetround,
etc. Note that speed is still very important, doing a store/read on a volatile
variable (the most portable optimization barrier) can make the whole
application 15% slower.
One common way to do that is to use an inline asm like:
asm volatile ("", "+g"(x));
(4.9 is the first version where this doesn't ICE all over the place on x86, use
"+m" earlier)
so no code is emitted but the value of x is hidden from the compiler. However,
the "g" constraint doesn't include FP registers. Depending if the code is
compiled for power, sparc, itanium, arm or x86_64, I need to add either "d",
"e", "f", "w", or "x" (yeah, there aren't 2 using the same letter). It looks
like there isn't even a letter for x87 (PR 59157). Using the more general "+X"
is tempting but ICEs (PR 59155).
There is at least one case this inline asm approach can never handle optimally:
constants. We need the variable as asm output or it won't have any effect. But
the constants are in a read-only location that is not suitable for an output
operand, so with "+m" gcc copies the constant to another memory location.
Ideally, there would be a __builtin_opaque built-in that does the right thing
and I wouldn't have to think about it...
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
@ 2013-11-17 15:31 ` joseph at codesourcery dot com
2013-11-17 16:03 ` glisse at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: joseph at codesourcery dot com @ 2013-11-17 15:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:
> propagation, or replace x*-y with -x*y, or move operations across fesetround,
Do you mean -(x*y)? I don't see the problem with replacing x*-y with
-x*y (which is (-x)*y), in any rounding mode.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
2013-11-17 15:31 ` [Bug c/59159] " joseph at codesourcery dot com
@ 2013-11-17 16:03 ` glisse at gcc dot gnu.org
2013-11-18 11:58 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-11-17 16:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #1)
> On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:
>
> > propagation, or replace x*-y with -x*y, or move operations across fesetround,
>
> Do you mean -(x*y)? I don't see the problem with replacing x*-y with
> -x*y (which is (-x)*y), in any rounding mode.
Yes, sorry, I meant -(x*y).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
2013-11-17 15:31 ` [Bug c/59159] " joseph at codesourcery dot com
2013-11-17 16:03 ` glisse at gcc dot gnu.org
@ 2013-11-18 11:58 ` rguenth at gcc dot gnu.org
2013-11-18 12:26 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-11-18 11:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-11-18
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, as you want to guard against propagation across FP state changes I'd
rather make that explicit (thus, not make it a generic no-op propagation
barrier).
Of course thinking about a better representation of FP state in the middle-end
would be better as requiring the user to pass every value through such a
built-in isn't a nice user interface (yeah, better than making up asms ...).
__builtin_protect (...)
for a generic name,
__builtin_protect_fenv (...)
for sth more specific. Both need to be type-generic and only result in
no overhead when the argument and return value are registers - consider
float f1, f2;
foo (&f1, &f2);
.. = __builtin_protect (f1);
.. = __builtin_protect (f2);
which would still cause a redundant load that cannot be optimized until
RTL optimization at least.
I wonder whether a very early pass splitting functions at FENV clobber
points and preventing re-inlining would be a better solution in the end
(yeah, making them nested with all the optimization side-effects that
causes, which also means _very_ early as unnesting happens more or less
during gimplification - or you re-invent unnesting in parts at least).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
` (2 preceding siblings ...)
2013-11-18 11:58 ` rguenth at gcc dot gnu.org
@ 2013-11-18 12:26 ` rguenth at gcc dot gnu.org
2013-11-18 13:27 ` joseph at codesourcery dot com
2021-09-15 21:11 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-11-18 12:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Or have a pass that automates your asm() barrier instrumentation for all values
that are life across a FENV affecting call.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
` (3 preceding siblings ...)
2013-11-18 12:26 ` rguenth at gcc dot gnu.org
@ 2013-11-18 13:27 ` joseph at codesourcery dot com
2021-09-15 21:11 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: joseph at codesourcery dot com @ 2013-11-18 13:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 18 Nov 2013, rguenth at gcc dot gnu.org wrote:
> I wonder whether a very early pass splitting functions at FENV clobber
> points and preventing re-inlining would be a better solution in the end
That sounds like a nasty hack, not a sensible solution for properly
supporting exceptions and rounding modes. For interval arithmetic you
want code changing rounding modes (or using the FENV_ROUND pragma proposed
in DTS 18661-1) to be handled reasonably efficiently rather than resulting
in a split into separate functions (really, a function with FENV_ACCESS
enabled should be inlinable into one without, though I could certainly
imagine an initial implementation controlling flags only on a per-function
basis and preventing inlining).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/59159] Need opaque pass-through as optimization barrier
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
` (4 preceding siblings ...)
2013-11-18 13:27 ` joseph at codesourcery dot com
@ 2021-09-15 21:11 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-15 21:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
__builtin_assoc_barrier is being implemented
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578935.html That
should solve part of this.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-15 21:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-17 11:41 [Bug c/59159] New: Need opaque pass-through as optimization barrier glisse at gcc dot gnu.org
2013-11-17 15:31 ` [Bug c/59159] " joseph at codesourcery dot com
2013-11-17 16:03 ` glisse at gcc dot gnu.org
2013-11-18 11:58 ` rguenth at gcc dot gnu.org
2013-11-18 12:26 ` rguenth at gcc dot gnu.org
2013-11-18 13:27 ` joseph at codesourcery dot com
2021-09-15 21:11 ` 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).