On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func across func does *not*
affect the interrupt respond times in such a disastrous way.
Thus you must
On Mon, Mar 3, 2014 at 11:41 AM, David Brown da...@westcontrol.com wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func across func does *not*
On 03/03/14 11:49, Richard Biener wrote:
On Mon, Mar 3, 2014 at 11:41 AM, David Brown da...@westcontrol.com wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but
On 03/03/14 14:54, Richard Biener wrote:
On Mon, Mar 3, 2014 at 1:53 PM, David Brown da...@westcontrol.com wrote:
On 03/03/14 11:49, Richard Biener wrote:
On Mon, Mar 3, 2014 at 11:41 AM, David Brown da...@westcontrol.com wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay
So, the main question is not about triggering condition, but about the
behavior itself. Is it correct to flush and reload all constants ? They are
constants after all, they are even not stored in .data section but inlined
in the code, and thus cannot be modified.
I'd think that everyone more
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov y.gri...@samsung.com writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive
Of course if the GIMPLE level doesn't care about the barrier then it doesn't
make sense to be overly conservative at the RTL CSE level. Thus I think we
can just remove this barrier completely.
Not clear to me, what happens e.g. for register variables?
--
Eric Botcazou
On Fri, Feb 28, 2014 at 10:23 AM, Eric Botcazou ebotca...@adacore.com wrote:
Of course if the GIMPLE level doesn't care about the barrier then it doesn't
make sense to be overly conservative at the RTL CSE level. Thus I think we
can just remove this barrier completely.
Not clear to me, what
Eric Botcazou ebotca...@adacore.com writes:
One of the big grey areas is what should happen for floating-point ops
that depend on the current rounding mode. That isn't really modelled
properly yet though. Again, it affects calls as well as volatile asms.
There is an explicit comment about
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func across func does *not*
affect the interrupt respond times in such a disastrous way.
Thus you must be *very* careful w.r.t. optimizing against
But here too the point is that we don't assume the same thing at the
tree level or during register allocation. It seems a bit silly for
the scheduler to assume that all hard registers are clobbered when the
register allocator itself doesn't assume that. And most rtl passes
assume that
Hi all,
We have recently ran into a performance/code size regression on ARM
targets after transition from GCC 4.7 to GCC 4.8 (this regression is
also present in 4.9).
The following code snippet uses Linux-style compiler barriers to protect
memory writes:
#define barrier() __asm__
After some investigation, we discovered that this behavior is caused by
big hammer in gcc/cse.c:
/* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
if (NONJUMP_INSN_P (insn)
volatile_insn_p (PATTERN (insn)))
flush_hash_table ();
This code (introduced
On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou ebotca...@adacore.com wrote:
After some investigation, we discovered that this behavior is caused by
big hammer in gcc/cse.c:
/* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
if (NONJUMP_INSN_P (insn)
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point though.
Though
Yury Gribov y.gri...@samsung.com writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could
On 27/02/14 16:36, Yury Gribov wrote:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a
Hi,
On Thu, 27 Feb 2014, Richard Sandiford wrote:
[... many cases where 'volatile' in asm doesn't inhibit optimizations
...]
We do nothing this draconian for a normal function call, which could
easily use a volatile asm internally. IMO anything that isn't flushed
for a call shouldn't be
Yury Gribov schrieb:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting
asm volatile + memory clobber should be the last resort barrier, if you skip
this out of the compiler or change its semantics (pinned by the current
documentation) at will, it's not unlikely you break existing code in favour
or saving some poor instructions.
Problem is that there is no
Hello!
This code (introduced in
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=193802) aborts
CSE after seeing a volatile inline asm.
Note that introduced is not really correct here, the code had been
there for a long time but it was treating some volatile asms as
barriers and
21 matches
Mail list logo
