Hi,
I started to look into mixed vector sizes (in the same loop). My main reason
for this was to allow widening and narrowing instructions, that have
different vector sizes for src and dest, to work properly. My example was
widen_mult (int = short * short), I thought its implementation was not
opt
Hi there. I've been going through the blueprints in preparation for
next weeks TSC review. The top level topics are good, and I'd like to
have the rest of the engineering blueprints checked over and updated
to match what we talked about at the summit.
Ira, could you please create blueprints for
Hi Andrew. Any news on the upstreaming? I'm happy for the Toolchain
WG to do the work as it helps Linaro as a whole, so if there's a patch
available then I'll ask Richard S or Chung-Lin to get it upstream.
Dave, has this been reported upstream?
-- Michael
On Sat, Nov 6, 2010 at 12:14 AM, Andre
On 09.11.2010 14:05, Andrew Stubbs wrote:
On 09/11/10 06:51, Michael Hope wrote:
I've been going through the ChangeLog for the release and am having
trouble justifying some of the changes brought in. In particular:
* -fstrict-volatile-bitfields, which is more appropriate for bare
metal/kernel co
On Tue, Nov 09, 2010, Mark Mitchell wrote:
> So, fundamentally, we have to choose whether we want to work as much as
> possible upstream (using an SVN branch), or whether we want uniformity
> across Linaro projects (using Launchpad).
This only lists political options; the quality of the tool shou
On 11/9/2010 6:11 AM, Ira Rosen wrote:
> I don't believe we will be able to get all the patches pre-approved and
> maintain a pure linaro-trunk anyway. For me the main value of SVN branch
> is an ability to make my work visible to GCC community and give them an
> opportunity to review the patches
On 9 November 2010 15:36, Andrew Stubbs wrote:
> On 09/11/10 12:55, Ira Rosen wrote:
>
>> * We can't really apply anything we want just for ourselves
>>
>> Why? It will be our "private" Linaro branch. We can apply whatever we
>> want there (we can also decide on reviewers and/or some submit/
Ira Rosen writes:
> On 9 November 2010 14:38, Andrew Stubbs <[1]...@codesourcery.com> wrote:
>
> Re my recent email "Upstream GCC feature freeze", I think we're agreed
> that we need to create a branch that tracks GCC 4.6 development, but has
> our own performance improvements included. The
On 09/11/10 06:51, Michael Hope wrote:
I've been going through the ChangeLog for the release and am having
trouble justifying some of the changes brought in. In particular:
* -fstrict-volatile-bitfields, which is more appropriate for bare
metal/kernel code
* Cortex-M4 support
* C locale su
On 09/11/10 12:55, Ira Rosen wrote:
* We can't really apply anything we want just for ourselves
Why? It will be our "private" Linaro branch. We can apply whatever we
want there (we can also decide on reviewers and/or some submit/commit
procedure). We can mark our patches with both [] and
On 9 November 2010 14:38, Andrew Stubbs wrote:
> Re my recent email "Upstream GCC feature freeze", I think we're agreed that
> we need to create a branch that tracks GCC 4.6 development, but has our own
> performance improvements included. The question is where to host it?
>
> Option 1: Launchpad
Re my recent email "Upstream GCC feature freeze", I think we're agreed
that we need to create a branch that tracks GCC 4.6 development, but has
our own performance improvements included. The question is where to host it?
Option 1: Launchpad/bzr
Pros:
* We need no permission to do it
* The br
Dnia wtorek, 9 listopada 2010 o 00:09:03 Michael Hope napisał(a):
> I agree on the approach. I'm concerned about moving over to SVN for a
> few reasons:
> harder merging (with bzr you do a 'bzr merge lp:gcc' and it does a good,
> three way merge with trunk. Last time I used svn for this it was a
Julian Brown wrote on 05/11/2010 12:58:14 PM:
> I think it's probably fine to default to 128-bit vectors, and fall back
> to 64-bits when necessary (where access patterns block usage of wider
> vectors, or similar). AIUI, ARM were quite keen to get rid of
> -mvectorize-with-neon-quad altogether
On 11/09/2010 02:51 PM, Michael Hope wrote:
>
> Our focus is time based performance on the Cortex-A series with an
> implied applications over kernel/bare metal. This is a very narrow
> view, but every non-performance line of code we bring in can also
> bring in a bug.
>
Can we explain this cri
15 matches
Mail list logo
