)
(arm_movmemqi_unaligned): New.
(arm_gen_movmemqi): Support unaligned block copies.
commit 16973f69fce37a2b347ea7daffd6f593aba843d5
Author: Julian Brown jul...@henry7.codesourcery.com
Date: Wed May 4 11:26:01 2011 -0700
Optimize block moves when unaligned accesses are permitted.
diff --git a/gcc/config/arm
Hi,
This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.
Tested manually only. OK to apply?
Thanks,
Julian
ChangeLog
gcc/
* config/arm/neon.md (vec_setmode_internal): Fix misplaced
On Wed, 9 Feb 2011 12:11:35 +
Julian Brown jul...@codesourcery.com wrote:
On Wed, 12 Jan 2011 17:38:22 +
Julian Brown jul...@codesourcery.com wrote:
This version of the patch tweaks target-supports.exp to say that
various operations are not available in big-endian mode (removing
On Thu, 24 Mar 2011 10:57:06 +
Richard Sandiford richard.sandif...@linaro.org wrote:
Chung-Lin Tang clt...@codesourcery.com writes:
PR48183 is a case where ARM NEON instrinsics, under -O -g, produce
debug insns that tries to expand OImode (32-byte integer) zero
constants, much too
On Mon, 11 Jan 2010 09:52:59 +
Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote:
cam-bc3-b12:ramrad01 68 ocamlc -c neon-schedgen.ml
File neon-schedgen.ml, line 51, characters 0-10:
Unbound module Utils
It sounds like a configuration issue but given my rather rusty ocaml
skills
On Wed, 3 Jun 2009 21:39:34 +1200
Michael Hope micha...@juju.net.nz wrote:
How does the combine stage work? It looks like it could get multiple
potential matches for a set of RTLs. Does it use some type of costing
function to pick between them? Can I tell combine that a umulhisi3 is
On Thu, 26 Feb 2009 15:54:14 +
Andrew Haley a...@redhat.com wrote:
Paul Brook wrote:
Well, but wouldn't it still be nice if
__builtin_return_address(N) was implemented for N0 by libcalling
into the unwinder for you? Obviously this would still have to
return NULL at runtime when
On Fri, 27 Feb 2009 13:32:11 +
Julian Brown jul...@codesourcery.com wrote:
GLIBC already knows how to do backtracing if the ARM-specific unwind
tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace.
I'm told this probably isn't true for upstream GLIBC -- but we
definitely have
On Fri, 27 Jun 2008 15:52:22 +0530
Mohamed Shafi [EMAIL PROTECTED] wrote:
If the condition in the 'if' instruction is satisfied the processor
will execute the next instruction or it will replace with a nop. So
this means that i can instructions similar to:
if eq Rx, Ry
add Rx, Ry
add
Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC, but I
wonder if this set of changes is worth the maintenance burden...
Steven Bosscher wrote:
On 3/28/07, Julian Brown [EMAIL PROTECTED] wrote:
Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC
On 2005-04-18, Mark Mitchell [EMAIL PROTECTED] wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary
On 2005-04-11, Julian Brown [EMAIL PROTECTED] wrote:
On 2005-04-10, Mark Mitchell [EMAIL PROTECTED] wrote:
* The DejaGNU testsuite has been run, and compared with a run of
the testsuite on the previous release of GCC, and no regressions are
observed.
If you are willing to help
safely hold only those functions whose
address is taken? (Or maybe that was assumed anyway?)
Julian
--
Julian Brown
CodeSourcery, LLC
801 - 814 of 814 matches
Mail list logo
