Jakub Jelinek wrote:
> And that's the right thing to do.
I concur. But the exchange case remains open.
> Please file an enhancement request in gcc bugzilla.
Done, 48986. I have also noticed several other missing
optimizations in this area, so I'm about to report them too.
Best regards,
On Fri, May 13, 2011 at 07:55:44AM +0200, Piotr Wyderski wrote:
> Jakub Jelinek wrote:
>
> > /* X86_TUNE_USE_INCDEC */
> > ~(m_PENT4 | m_NOCONA | m_CORE2I7 | m_GENERIC | m_ATOM),
> >
> > So, if you say -mtune=bdver1 or -mtune=k8, it will generate incl,
> > if addl is better (e.g. on Atom incl is
Jakub Jelinek wrote:
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_CORE2I7 | m_GENERIC | m_ATOM),
>
> So, if you say -mtune=bdver1 or -mtune=k8, it will generate incl,
> if addl is better (e.g. on Atom incl is very bad compared to addl $1),
> it will generate it.
Why is lock inc/dec wo
On Thu, May 12, 2011 at 06:11:59PM +0200, Piotr Wyderski wrote:
> Unfortunately, onx86/x64 both are compiled in a rather poor way:
>
> __sync_increment:
>
> lock addl $x01,(ptr)
>
> which is longer than:
>
>lock incl (ptr)
GCC actually generates lock incl (ptr) already now, it just dep
On Thu, May 12, 2011 at 06:11:59PM +0200, Piotr Wyderski wrote:
> Hello,
>
> I'm not sure if it should be better handled as missed optimization,
> but there is a certain lack of functionality in the GCC's __sync_*
> function family.
>
> When implementing a reference counting smart pointer, two op
On Thu, 12 May 2011, Piotr Wyderski wrote:
> Hello,
>
> I'm not sure if it should be better handled as missed optimization,
> but there is a certain lack of functionality in the GCC's __sync_*
> function family.
I don't think we should add new functions to that family; instead the aim
should be
