On 03/03/14 14:54, Richard Biener wrote:
> On Mon, Mar 3, 2014 at 1:53 PM, David Brown wrote:
>> On 03/03/14 11:49, Richard Biener wrote:
>>> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
> Georg-Johann Lay writes:
>> Notice that in
On Mon, Mar 3, 2014 at 1:53 PM, David Brown wrote:
> On 03/03/14 11:49, Richard Biener wrote:
>> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
>>> On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay writes:
> Notice that in code1, func might contain such asm-pairs to impl
On 03/03/14 11:49, Richard Biener wrote:
> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
>> On 28/02/14 13:19, Richard Sandiford wrote:
>>> Georg-Johann Lay writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func acros
On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
> On 28/02/14 13:19, Richard Sandiford wrote:
>> Georg-Johann Lay 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 resp
On 28/02/14 13:19, Richard Sandiford wrote:
> Georg-Johann Lay 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
> 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 c
Georg-Johann Lay 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 asm volati
Eric Botcazou 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 this in the sch
On Fri, Feb 28, 2014 at 10:23 AM, Eric Botcazou 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 happens e.g. f
> 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
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov 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
On Fri, Feb 28, 2014 at 9:51 AM, Eric Botcazou wrote:
>> 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 co
> 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 m
> I think part of the problem is that some parts of GCC (like the one you
> noted) are far more conservative than others. E.g. take:
>
> void foo (int x, int *y)
> {
> y[0] = x + 1;
> asm volatile ("# asm");
> y[1] = x + 1;
> }
>
> The extra-paranoid check you pointed out means
Hello!
> > This code (introduced in
> > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=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
> ba
> 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 cur
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 point
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
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.
>
Yury Gribov 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
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 with
On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou 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)
>> && volatile_insn_p (PA
> 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 (int
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__ __volat
24 matches
Mail list logo
