--- Comment #13 from pinskia at gcc dot gnu dot org 2009-11-21 09:12
---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-11-21 09:13
---
Mark this as fixed for 4.5:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20gotoAs
of GCC version 4.5, asm goto may be used to have the assembly jump to one or
more C labels. In this
--- Comment #9 from scovich at gmail dot com 2009-05-13 07:55 ---
RE: __builtin_expect -- Thanks! It did help quite a bit, even though the
compiler was already emitting not-taken branch hints on its own.
RE: Filing bugs -- I have. This RFE arose out of Bug #40078, which was
triggered
--- Comment #10 from jakub at gcc dot gnu dot org 2009-05-13 08:19 ---
Of course there is a very important reason. If you allow inline asms to change
control flow, even just to labels whose address has been taken through label,
you penalize a lot of code which doesn't change the
--- Comment #11 from scovich at gmail dot com 2009-05-13 09:51 ---
If you allow inline asms to change control flow, even just
to labels whose address has been taken through label, you
penalize a lot of code which doesn't change the control
flow, as the compiler will have to
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-13 09:58
---
I strongly oppose to making asm handling even more complex.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 16:05 ---
GCC can already produce good code for overflow catching on x86. I think it is
better if you don't use inline-asm for this case at all and just write the
overflow detection in C90/C99 (which means don't cause an
--- Comment #2 from scovich at gmail dot com 2009-05-12 16:13 ---
Overflow and adc were only examples. Other instructions that set cc, or other
conditions (e.g. parity) would not have that optimization.
Another use is the ability to jump out of an inline asm to handle an uncommon
case
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-12 16:23 ---
We are investigating if we need to add non-SSE intrinsics into gcc.
If you can show me an example where gcc can't generate similar
code automatically vs inline asm statement, I will look into if
we should add some
--- Comment #4 from scovich at gmail dot com 2009-05-12 16:36 ---
I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
more people know it and its asm is easier to read).
My use case is the following: I'm implementing high-performance synchronization
primitives
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-12 16:42 ---
(In reply to comment #4)
I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
more people know it and its asm is easier to read).
My use case is the following: I'm implementing
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-12 16:48 ---
Sounds like you want to use __builtin_expect.
Also GCC uses heuristics to figure out:
if(pred)
is taken most of the time because it is comparing a pointer to NULL.
--
--- Comment #7 from scovich at gmail dot com 2009-05-12 17:01 ---
Isn't __builtin_expect a way to send branch prediction hints? I'm not having
trouble with that AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-05-12 17:08 ---
(In reply to comment #7)
Isn't __builtin_expect a way to send branch prediction hints?
Not just prediction hints, it helps other optimizations of not moving code
around inter block which seems like what you need.
14 matches
Mail list logo
