On Sat, 19 Aug 2023 10:47:45 +0400
Maxim Kuvyrkov wrote:
> Hi Julian,
>
> Your patch series causes regressions on aarch64-linux-gnu. Would you
> please investigate?
>
> Let me know if you need any assistance in reproducing these.
Hi Maxim!
I'm a little confused -- to be clear, those patches
On Tue, 22 Feb 2011 09:42:15 +
Richard Sandiford wrote:
> Julian Brown writes:
> > Richard Sandiford wrote:
> > 1. Struct (tree) types are defined via hard-wired code in the ARM
> > backend rather than in arm_neon.h. The "type mode" of those struct
> &g
On Tue, 8 Feb 2011 11:22:32 +
Julian Brown wrote:
> IIRC I couldn't figure out the magic incantation needed to do it last
> time I tried. I don't think the "--with-endian=xxx" option is
> supported for ARM. Possibly the way to do it is to configure for
> the
On Tue, 8 Feb 2011 09:33:21 +0200
Ira Rosen wrote:
> On 7 February 2011 18:24, Julian Brown
> wrote:
> > Building for big-endian ARM is Really Hard (IMO) :-). You can't
> > intermix little-endian and big-endian objects at all, so you either
> > need an entirely-big
On Mon, 7 Feb 2011 17:18:40 +0200
Ira Rosen wrote:
> Hi,
>
> I'd like to check vzip/vuzp patch in big endian mode. But when I try
> to compile with -mbig-endian flag, I get
>
> > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon
> > neon-vtrnu8.c -mbig-endian
> /home/irar/mainline/bin/li
== Linaro GCC ==
* Continued hacking on (cleaning up, testing) NEON
element/structure load/store (etc.) intrinsics-improvement patch. This
now passes all the auto-generated neon.exp tests (admittedly only a
very weak test for correctness), and the small number of hand-written
tests I threw at it,
== Linaro GCC ==
* Continued looking at element/structure load/store intrinsics
improvements. Some good initial results: it looks like the plan of
using "extra-wide" vectors for returning struct results works fine (at
least to a first approximation). Sent off WIP patch (internally to CS
only, so
== Linaro GCC ==
* Finish testing for big-endian/quad-word patch on mainline, and
send upstream. Not yet reviewed by an ARM maintainer, but Joseph
suggested tweaking DejaGnu's target-supports to better reflect the new
capabilities of the vectorizer in big-endian mode. I've not looked into
that ye
On Thu, 09 Dec 2010 14:42:49 +
Andrew Stubbs wrote:
> On 26/11/10 11:11, Andrew Stubbs wrote:
> > As we discussed on Monday, I think it might be helpful to get a
> > number of knowledgeable people together on a call to discuss GCC
> > optimization opportunities.
> >
> > So, I'd like to get so
== Linaro GCC ==
* Worked on quad-word/big-endian fixes patch. Sent off a version
on Tuesday which worked OK, but which made some awkward changes to the
middle-end. Tried to re-think those parts, but without much luck: came
to the conclusion that spending more time trying to fix
element-ordering-
On Wed, 1 Dec 2010 11:16:16 +0200
Ira Rosen wrote:
> >> > v0 = MEM_REF (addr)
> >> > v1 = MEM_REF (addr + 8B)
> >> > v2 = MEM_REF (addr + 16B)
> >> > builtin (v0, v1, v2, stride=3, reg_stride=1,...)
> >
> > Would the builtin be changing the semantics of the preceding MEM_REF
> > codes? If so I do
On Tue, 30 Nov 2010 16:06:32 + (UTC)
"Joseph S. Myers" wrote:
> On Tue, 30 Nov 2010, Julian Brown wrote:
>
> > * defaults.h (VECTOR_ELEMENTS_BIG_ENDIAN): Define.
>
> Apart from the point that new target macros should be hooks, the
> *very first* thing t
On Wed, 17 Nov 2010 11:21:03 +
Julian Brown wrote:
> Shouldn't be more than 1-2 days, but I've been distracted by other
> bugs...
Well, this took a little longer than I thought. I think it's a good
incremental improvement though: it should improve code in a few cases
On Tue, 30 Nov 2010 12:25:18 +0200
Ira Rosen wrote:
> On 22 November 2010 13:46, Ira Rosen wrote:
> > On 17 November 2010 13:21, Julian Brown
> > wrote:
> >>> > We'd need to figure out what the RTL for such loads/stores
> >>> > should
== Linaro GCC ==
* Finished testing patch for lp675347 (QT inline-asm atomics), and
send upstream for comments (no response yet). Suggested reverting a
patch (which enabled -fstrict-volatile-bitfields by default on ARM)
locally for Ubuntu in the bug log.
* Continued working on NEON quad-word ve
== 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
On Wed, 17 Nov 2010 12:16:34 +0200
Ira Rosen wrote:
> On 15 November 2010 17:33, Julian Brown
> wrote:
>
> > On Mon, 15 Nov 2010 10:12:26 +0200
> > Ira Rosen wrote:
> >
> > > Do you think now that the changes in GIMPLE and RTL (a function
> >
On Mon, 15 Nov 2010 10:12:26 +0200
Ira Rosen wrote:
> Hi Julian,
>
> On 12 November 2010 17:49, Julian Brown
> wrote:
> > ...
> > The important observation is that vectors from case 1 and from
> > cases 2/3 never interact: it's quite safe for them to
Hi,
Here's a work-in-progress patch which fixes many execution failures
seen in big-endian mode when -mvectorize-with-neon-quad is in effect
(which is soon to be the default, if we stick to the current plan).
But, it's pretty hairy, and I'm not at all convinced it's not working
"for the wrong reas
On Wed, 3 Nov 2010 14:57:01 +0200
Ira Rosen wrote:
> > -mfloat-abi=softfp/-mfloat-abi=hard -mfpu=neon* [-march=armv7-a]
> >
> > * there are several variants for this, e.g. neon, neon-fp16,
> > neon-vfpv4 ... generally -mfpu=neon should do though, for Cortex-A8
> > chips at least.
>
> gcc.dg/vec
On Mon, 1 Nov 2010 15:57:11 +0200
Ira Rosen wrote:
> It looks like it's enough to implement targetm.vectorize.
> autovectorize_vector_sizes for NEON in order to enable initial
> auto-detection of vector size. With the attached patch and
> -mvectorize-with-neon-quad flag, the vectorizer first trie
or vectors seems
like it will be a necessary addition to the vectorizer, going forward.
Julian
Begin forwarded message:
Date: Thu, 7 Oct 2010 16:45:17 +0100
From: Julian Brown
To: Ira Rosen
Cc: Tejas Belagod , Linaro List
Subject: [gnu-linaro-tools] NEON
vectorization: use of specialized load/stor
Hi,
In case this is useful in its current (unfinished!) form: here are some
notes I made whilst looking at a couple of the items listed for CS308
here:
https://wiki.linaro.org/Internal/Contractors/CodeSourcery
Namely:
* automatic vector size selection (it's currently selected by command
On Tue, 07 Sep 2010 21:06:10 +0800
Yao Qi wrote:
> Julian Brown wrote:
> > So yeah, I think there is indeed a possible improvement here (and we
> > don't even need to break the EABI, I don't think). Unless I've
> > overlooked something, anyway...
> Julian,
On Tue, 7 Sep 2010 12:55:59 +0200
Loïc Minier wrote:
> On Tue, Sep 07, 2010, Julian Brown wrote:
> > Do
> > you still have the code fragment handy (I don't remember exactly how
> > it went)?
>
&
On Mon, 06 Sep 2010 14:16:25 +0800
Yao Qi wrote:
> Yao Qi wrote:
> > Hi,
> > We are looking for some possible improvements and optimizations on
> > thumb2 code size. Currently, I am running some benchmarks with
> > compilation flag "-Os -march=armv7-a -mthumb", and hope to find some
> > thing in
On Tue, 17 Aug 2010 11:00:13 +0100
Peter Maydell wrote:
> On 16 August 2010 23:07, Michael Hope wrote:
> > -- Julian Brown
> > == GCC 4.5 vectorization improvements ==
> >
> > * Started tracking down the causes of some failures in vect.exp:
> > pr43430-1.c
(Re-sending to linaro-toolchain@lists.linaro.org, since I
accidentally haven't been subscribed to that. Whoops!)
On Tue, 17 Aug 2010 11:00:13 +0100
Peter Maydell wrote:
> On 16 August 2010 23:07, Michael Hope wrote:
> > -- Julian Brown
> > == GCC 4.5 vector
On Wed, 4 Aug 2010 22:53:46 +0800
Yao Qi wrote:
> LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and
> LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are
> related to this patch below. You can get more details from comments
> of these bugs, since I've added my underst
29 matches
Mail list logo
