Re: RFC: -mimplicit-it and GCC upstream

2010-11-22 Thread Dave Martin
On Wed, Nov 17, 2010 at 11:22 AM, Dave Martin wrote: > On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope wrote: >> In general the product should move forward and drop work-arounds like >> -mimplicit-it.  We (the greater ARM community) should fix these >> package problems as they are found.  Here's a

[ACTIVITY] 15th - 19th November

2010-11-22 Thread Andrew Stubbs
LP:663939 - Thumb2 constants * Continued testing, found a few bugs. Tidied a few bits up. * Wrote some new testcases to go with the patch. LP:618684 - ICE * Begun looking at this one. So far I can't reproduce it. I have a debuggable native toolchain building, but it'd been delayed by hardw

Of instruction timings

2010-11-22 Thread David Gilbert
Hi Richard, As per the discussion at this mornings call; I've reread the TRM and I agree with you about the LSLS being the same speed as the TST. (1 cycle) However as we agreed, the uxtb does look like 2 cycles v the AND 1 cycle. On the space v perf theme, one thing that would be interesting to

__sync barriers

2010-11-22 Thread Richard Sandiford
For the record, the thing I half-remembered on the call was: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html and: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html The problem is that all __sync operations besides __sync_lock_test_and_set and __sync_lock_release are defined

Re: [PATCH, WIP] NEON quadword vectors in big-endian mode (#10061, #7306)

2010-11-22 Thread Ira Rosen
On 17 November 2010 13:21, Julian Brown wrote: >> > We'd need to figure out what the RTL for such loads/stores should >> > look like, and whether it can represent alignment constraints, or >> > strides, or loads/stores of multiple vector registers simulateously. Alignment info is kept in struct p

Re: RFC: -mimplicit-it and GCC upstream

2010-11-22 Thread Nicolas Pitre
On Mon, 22 Nov 2010, Dave Martin wrote: > So I've now come round to the view that we _should_ probably bite the > bullet and fix the inline asm directly. So: > >* We need to verify which binutils permit (and ignore) the IT > instructions in non-unified (ARM) syntax. I've observed that 2.19.

[ACTIVITY] November 15-21st

2010-11-22 Thread Julian Brown
== Linaro GCC == * Continued looking at big-endian/quad-vector patch: attempted to figure out the proper semantics for vec_extract in big endian mode (about 1 day). Put on hold temporarily to work on lp675347, QT failing to build due to constraint failure in inline asm statements used for atomic

Status Report 11-22-2010

2010-11-22 Thread Zach Welch
== Last Week == * Reached the point with understanding libunwind where I can begin writing patches for parsing unwind information out of .ARM.exidx and .ARM.extab ELF sections. == This Week == * Begin writing support for ARM-specific unwind information to libunwind. -- Zach Welch CodeSourcery

Re: RFC: -mimplicit-it and GCC upstream

2010-11-22 Thread Dave Martin
Hi, On Mon, Nov 22, 2010 at 2:39 PM, Nicolas Pitre wrote: [...] > I hope there is at least a validation of the IT instructions by the > assembler with regards to the condition codes on the following > instructions (and vice versa) to make sure they are all coherent, and > even so for ARM mode c

Re: __sync barriers

2010-11-22 Thread Michael Hope
On Tue, Nov 23, 2010 at 12:34 AM, Richard Sandiford wrote: > For the record, the thing I half-remembered on the call was: > >    http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html > and: >    http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html > > The problem is that all __sync operations