2012-02-28 Andrew Stubbs
gcc/
* config/arm/arm.c (neon_valid_immediate): Allow const_int.
* config/arm/constraints.md (Dn): Allow const_int.
* config/arm/neon.md (neon_mov): Use VDX to allow DImode.
* config/arm/predicates.md (imm_for_neon_mov_operand): Allow const_int.
* config/arm/vfp.md
when combined with my recent patch for
NEON DImode immediates. Without that you get a constant pool load.)
OK for 4.8?
Andrew
2012-02-28 Andrew Stubbs
gcc/
* config/arm/arm.md (negdi2): Use gen_negdi2_neon.
* config/arm/neon.md (negdi2_neon): New insn_and_split.
---
gcc/config/arm/arm.md |
On 28/02/12 17:45, Andrew Stubbs wrote:
This patch adds a DImode negate pattern for NEON.
Oops, that patch completely failed to allow for the fallback to
instructions that work in core registers. It also forgot to mention that
the CC register was clobbered.
This patch is the same except
DImode (in addition to the
vector modes already supported) and retains the support for doing
bitwise not in core registers where appropriate.
OK for 4.8?
Andrew
2012-02-29 Andrew Stubbs
gcc/
* config/arm/arm.md (one_cmpldi2): Rename to one_cmpldi2_internal
and replace with a new
On Wed 29 Feb 2012 18:00:19 GMT, Richard Earnshaw wrote:
Why can't we have a single insn that deals with the have-neon and
dont-have-neon cases?
Sorry, I'm not sure I follow?
There's one insn for the have-neon case, and one for the
don't-have-neon. The expander is necessary to prevent gen_one
mlaltb/smlaltt also (I'll post that in a
separate patch).
It does assume that the outer sign_extend/zero_extend indicates the
inner extend types though, so I'm not sure if there's a problem there?
OK?
Andrew
2011-05-24 Bernd Schmidt
Andrew Stubbs
gcc/
* simplify-rtx
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplifie
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplifie
On 25/05/11 14:19, Joseph S. Myers wrote:
RTL has defined abstract semantics and RTL transformations should be ones
that are valid in accordance with those semantics, with proper assertions
if there are additional constraints on the input passed to a function.
This means actually counting the num
t you describe.
Is the patch OK now?
Andrew
2011-05-26 Bernd Schmidt
Andrew Stubbs
gcc/
* simplify-rtx.c (simplify_unary_operation_1): Canonicalize widening
multiplies.
* doc/md.texi (Canonicalization of Instructions): Document widening
multiply canonicalization.
gcc/testsuite/
* gcc.t
ch until my other patch for canonical
mult patterns is applied.
OK?
Andrew
2011-05-27 Andrew Stubbs
gcc/
* config/arm/arm.md (*maddhidi4tb, *maddhidi4tt): New define_insns.
(*maddhisi4tb, *maddhisi4tt): New define_insns.
gcc/testsuite/
* gcc.target/arm/smlatb-1.c: New file.
* gcc.ta
On 31/05/11 16:27, Dmitry Plotnikov wrote:
Would you include this in your patch? Or should we submit it as a
separate patch?
I'm not sure I *can* commit your patches, legally speaking, although
this one is small enough that probably it's ok ... probably.
Perhaps you should submit it yourself
Ping 2.
On 20/04/11 16:27, Andrew Stubbs wrote:
This patch adds basic support for the Thumb ADDW and SUBW instructions.
The patch permits the compiler to use the new instructions for constants
that can be loaded with a single instruction (i.e. 16-bit unshifted),
but does not support use of
On 02/06/11 09:23, Ramana Radhakrishnan wrote:
Please remove the alternatives in the subsi3 pattern since that is just
unnecessary. Please make the constraints internal only.
Is this better?
Andrew
2011-06-02 Andrew Stubbs
gcc/
* config/arm/arm-protos.h (const_ok_for_op): Add prototype
On 06/06/11 13:15, Dmitry Plotnikov wrote:
+ && (const_ok_for_op (INTVAL (x), outer)
+ || const_ok_for_op (~INTVAL (x), outer
The second call is redundant. const_ok_for_op should already do that.
Andrew
On 06/06/11 14:26, Dmitry Plotnikov wrote:
if (const_ok_for_arm (INTVAL (x))
- || const_ok_for_arm (~INTVAL (x)))
+ || const_ok_for_arm (~INTVAL (x))
+ || (TARGET_THUMB2&& outer == PLUS
+ && (const_ok_for_op (INTVAL (x), outer
Sorry, I should have not
On 06/06/11 15:26, Dmitry Plotnikov wrote:
On 06/06/2011 05:33 PM, Andrew Stubbs wrote:
On 06/06/11 14:26, Dmitry Plotnikov wrote:
if (const_ok_for_arm (INTVAL (x))
- || const_ok_for_arm (~INTVAL (x)))
+ || const_ok_for_arm (~INTVAL (x))
+ || (TARGET_THUMB2&& outer
On 02/06/11 10:46, Richard Earnshaw wrote:
OK.
Committed, thanks.
Andrew
On 02/06/11 16:47, Richard Earnshaw wrote:
OK.
Committed, thanks.
Andrew
Hi all,
This patch series is intended to improve use of widening multiply, and
widening multiply-and-accumulate instructions. This is primarily for the
benefit of ARM targets, but should give some improvements to other
targets also.
The patches provide a number of improvements:
* Support f
have a widening add, shift, or whatever.
Is this patch OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* expr.c (expand_expr_real_2): Use widening_optab_handler.
* genopinit.c (optabs): Use set_widening_optab_handler for $N.
(gen_insn): $N now means $a must be wider than $b, n
quot;type2" were implicitly identical because they
were required to be one mode smaller than "type".
I regard the ARM portion of this patch as obvious, so I don't think I
need an ARM maintainer to read this.
Is the patch OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* conf
-23 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Look for
multiply statement beyond NOP_EXPR statements.
gcc/testsuite/
* gcc.target/arm/umlal-1.c: New file.
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/umlal-1.c
@@ -0,0 +1,10 @@
+/* { dg-do compile
guarantee by
zero-extending the inputs to a wider mode (which must still be narrower
than the output mode).
OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* Makefile.in (tree-ssa-math-opts.o): Add langhooks.h dependency.
* optabs.c (find_widening_optab_handler): Rename to
being the input
type of the operation, and the gimple verification code is still valid.
OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (is_widening_mult_p): Remove FIXME.
Ensure the the larger type is the first operand.
(convert_mult_to_widen): Insert cast if type2 is
re not being widened), so the pattern match failed.
The patch fixes these issues by making the output type explicit, and by
permitting unconverted inputs (the types are still checked, so this is
safe).
OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (is_widening_mult_rhs_
inputs may still have to be extended to fit the nearest
available instruction, so it doesn't make a difference every time.
OK?
Andrew
2011-06-23 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (convert_mult_to_widen): Better handle
unsigned inputs of different
On 23/06/11 17:26, Richard Guenther wrote:
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs wrote:
There are many cases where the widening_mult pass does not recognise
widening multiply-and-accumulate cases simply because there is a type
conversion step between the multiply and add statements
On 25/06/11 15:12, Bernd Schmidt wrote:
That all sounds good, but missing from this list is something that
occurs on many CPUs - widening from the high part of a register. The
current machinery only recognizes lowxlow widening multiplication, but
hardware often exists for highxlow and highxhigh.
at any point.
I've also changed the test cases to address Janis' comments.
Andrew
2011-06-28 Andrew Stubbs
gcc/
* gimple.h (tree_ssa_harmless_type_conversion): New prototype.
(tree_ssa_strip_harmless_type_conversions): New prototype.
(harmless_type_conversion_p): New prototype.
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That works fine, but only if the target supports those operations
directly. Otherwise, it
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That works fine, but only if the target supports
On 23/06/11 15:41, Andrew Stubbs wrote:
This patch removes the restriction that the inputs to a widening
multiply must be of the same mode.
It does this by extending the smaller of the two inputs to match the
larger; therefore, it remains the case that subsequent code (in the
expand pass, for
On 23/06/11 15:42, Andrew Stubbs wrote:
This patch fixes the case where widening multiply-and-accumulate were
not recognised because the multiplication itself is not actually widening.
This can happen when you have "DI + SI * SI" - the multiplication will
be done in SImode as a no
On 28/06/11 16:53, Michael Matz wrote:
On Tue, 28 Jun 2011, Richard Guenther wrote:
I'd name the predicate value_preserving_conversion_p which I think is
what you mean. harmless isn't really descriptive.
Note that you include non-value-preserving conversions, namely int ->
unsigned int.
It s
On 23/06/11 15:43, Andrew Stubbs wrote:
Patch 4 introduced support for using signed multiplies to code unsigned
multiplies in a narrower mode. Patch 5 then introduced support for
mis-matched input modes.
These two combined mean that there is case where only the smaller of two
inputs is unsigned
re are about what sort of cast sequences can
exist? Is this necessary? I haven't managed to coax it to generated any
examples of extends followed by truncates myself, but in any case, it's
hardly any code and it'll make sure it's future proofed.
OK?
Andrew
2011-06-
On 28/06/11 15:14, Andrew Stubbs wrote:
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That
On 28/06/11 16:08, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
This patch removes the restriction that the inputs to a widening
multiply must be of the same mode.
It does this by extending the smaller of the two inputs to match the
larger; therefore, it remains the case that
On 28/06/11 16:30, Andrew Stubbs wrote:
On 23/06/11 15:42, Andrew Stubbs wrote:
This patch fixes the case where widening multiply-and-accumulate were
not recognised because the multiplication itself is not actually
widening.
This can happen when you have "DI + SI * SI" - the mult
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings, (int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so sure. I'll look into it a bit further.
+/* Ch
On 07/07/11 11:04, Richard Guenther wrote:
Both types are equal, so please share the temporary variable you
create
+ rhs1 = build_and_insert_cast (gsi, gimple_location (stmt),
+ create_tmp_var (type1, NULL),
rhs1, type1);
+ rhs2 = build_and_i
On 07/07/11 11:26, Andrew Stubbs wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings,
(int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so
On 07/07/11 13:37, Richard Guenther wrote:
I'll cook up a quick patch for VRP.
Like the attached. I'll finish and properly test it.
Your patch appears to do the wrong thing for this test case:
int
foo (int a, short b, short c)
{
int bc = b * c;
return a + (short)bc;
}
With your patch,
On 23/06/11 15:37, Andrew Stubbs wrote:
This patch should have no effect on the compiler output. It merely
replaces one way to represent widening operations with another, and
refactors the other parts of the compiler to match. The rest of the
patch set uses this new framework to implement the
ontinue to have to be careful about casting unsigned
variables whenever they expect purely unsigned math. :(
Is this one ok?
Andrew
2011-07-11 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion statement separating multiply-and-accumulate.
On 23/06/11 15:39, Andrew Stubbs wrote:
This patch has two effects:
1. It permits the use of widening multiply instructions that widen by
more than one mode. E.g. HImode -> DImode.
2. It enables the use of widening multiply instructions for (extended)
inputs of narrower mode than
On 12/07/11 11:35, Georg-Johann Lay wrote:
+(define_insn "*mulsu"
+ [(set (match_operand:HI 0 "register_operand" "=r")
+(mult:HI (sign_extend:HI (match_operand:QI 1 "register_operand" "a"))
+ (zero_extend:HI (match_operand:QI 2 "register_operand"
On 12/07/11 12:11, Bernd Schmidt wrote:
2. There's no need to define both of these. For one thing, putting a '%'
at the start of the constraint list for operand 1 does precisely this,
Unfortunately it doesn't. It won't swap the sign/zero-extend.
Ah, my mistake. I still think that one form sh
On 12/07/11 12:05, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Hmmm, presumably the problem is that we might have a compatible
precision, but the backends actually work with purely mo
On 04/07/11 15:26, Andrew Stubbs wrote:
On 28/06/11 15:14, Andrew Stubbs wrote:
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned
type
then the compiler will attempt to use usmul_widen_optab or
t (in fact, they may have been wrong before).
Is this version OK?
Andrew
2011-07-14 Andrew Stubbs
gcc/
* config/arm/arm.md (maddhidi4): Remove '*' from name.
* expr.c (expand_expr_real_2): Use find_widening_optab_handler.
* optabs.c (find_widening_optab_handler_and_mode): New fu
This update changes only the context modified by changes to patch 2. The
patch has already been approved. I'm just posting it for completeness.
Andrew
2011-07-14 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion statement separ
On 12/07/11 15:07, Andrew Stubbs wrote:
This update does the same thing as before, but updated for the changes
earlier in the patch series. In particular, the build_and_insert_cast
function and find_widening_optab_handler_and_mode changes have been
moved up to patch 2.
And this update changes
I've updated this patch following the changes earlier in the patch
series. There isn't much left.
This should obviate all the review comments. :)
OK?
Andrew
2011-07-14 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (is_widening_mult_p): Remove FIXME.
Ensure the the larger type is
ltiply did
not come from an assign statement (this can happen when the value comes
from a function parameter).
This patch fixes that case, and updates the context changed by my
updates earlier in the patch series.
OK?
Andrew
2011-07-14 Andrew Stubbs
gcc/
* tree-ssa-math-
On 28/06/11 17:23, Andrew Stubbs wrote:
On 23/06/11 15:43, Andrew Stubbs wrote:
Patch 4 introduced support for using signed multiplies to code unsigned
multiplies in a narrower mode. Patch 5 then introduced support for
mis-matched input modes.
These two combined mean that there is case where
Ping. This is the last unreviewed patch in this series ...
Thanks
Andrew
On 09/07/11 15:43, Andrew Stubbs wrote:
On 23/06/11 15:37, Andrew Stubbs wrote:
This patch should have no effect on the compiler output. It merely
replaces one way to represent widening operations with another, and
series, but I've already regenerated the whole lot several times, it's
getting confusing, and they're all approved already, so I'm just going
to tack this one on the end.
Andrew
2011-07-18 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Con
On 19/07/11 00:33, Janis Johnson wrote:
On 07/14/2011 07:16 AM, Andrew Stubbs wrote:
{ dg-options "-O2 -march=armv7-a" }
The tests use "{ dg-options "-O2 -march=armv7-a" }" but -march will be
overridden for multilibs that specify -march, and might conflict with
o
matching. This also required
inserting new SSA_NAMEs to make it work.
In order to insert the new SSA_NAME, I've simply reused the existing
type conversion code - the only difference is that the conversion may be
a no-op, so it just generates a straight forward assignment.
OK?
Andre
not affect the addition
operation. That said, it really ought to remain correct or else bad
things could happen in later optimizations
Here is the patch I plan to commit, when patch 1 is approved, and my
testing is complete.
Andrew
2011-07-21 Andrew Stubbs
gcc/
* tree-ssa-math
On 21/07/11 20:29, Joseph S. Myers wrote:
On Tue, 12 Jul 2011, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Arithmetic on such types is a perfectly reasonable notion to have in
langua
On 21/07/11 14:22, Richard Guenther wrote:
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs wrote:
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused an internal
compiler error when the input to a multiply was a constant. This was
ENOPATCH
On 22/07/11 12:57, Andrew Stubbs wrote:
On 21/07/11 14:22, Richard Guenther wrote:
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs
wrote:
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused an
internal
compiler
On 22/07/11 13:34, Bernd Schmidt wrote:
@@ -1242,7 +1242,8 @@ expand_binop_directly (enum machine_mode mode, optab
binoptab,
>rtx target, int unsignedp, enum optab_methods methods,
>rtx last)
>{
> - enum insn_code icode = optab_handler (binoptab, mod
On 22/07/11 14:28, Bernd Schmidt wrote:
Oh well, let's shelve it and do it later.
Here's an updated patch with the formatting problem you found fixed.
OK?
Andrew
2011-07-22 Andrew Stubbs
gcc/
* expr.c (expand_expr_real_2): Use widening_optab_handler.
* genopinit.c (op
On 22/07/11 13:17, Richard Guenther wrote:
Ok.
I found a NULL-pointer dereference bug.
Fixed in the attached. I'll commit this version when the rest of my
testing is complete.
Thanks
Andrew
2011-07-22 Andrew Stubbs
gcc/
* tree-ssa-math-opts.c (is_widening_mult_rhs_p): H
Hi,
This old patch has been carried in the CodeSourcery toolchain for some
time now. It just adds a few new testcases for vectorization.
OK?
Andrew
2008-12-03 Daniel Jacobowitz
gcc/testsuite/
* gcc.dg/vect/vect-shift-3.c, gcc.dg/vect/vect-shift-4.c: New.
* lib/target-supports.exp (chec
e exported from static libgcc only,
with the symbol versioning ensuring they don't get exported from shared
libgcc).
No, there was no reason - I just didn't realise it needed doing.
Is this patch better?
Andrew
2011-04-14 Andrew Stubbs
gcc/
* config/arm/arm.c (arm_init_libfuncs):
Ping.
On 25/03/11 16:19, Andrew Stubbs wrote:
On 28/01/11 15:20, Richard Earnshaw wrote:
On Fri, 2011-01-28 at 15:13 +, Andrew Stubbs wrote:
On 28/01/11 14:12, Richard Earnshaw wrote:
So what happens to a variation of your testcase:
long long foolong (long long x, short *a, short *b
This patch removes some redundant code that caused me some confusion.
It's not possible to construct a constant from multiple ORN
instructions, just as it's not possible to do it with multiple AND
instructions.
OK?
Andrew
2011-04-20 Andrew Stubbs
gcc/
* config
required then.
OK?
Andrew
2011-04-20 Andrew Stubbs
gcc/
* config/arm/arm.c (arm_gen_constant): Move mowv support
(const_ok_for_op): ... to here.
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2461,6 +2461,13 @@ const_ok_for_op (HOST_WIDE_INT i, enum rtx_code code)
coming soon.
This patch requires that my previously posted patch for MOVW is applied
first.
OK?
Andrew
2011-04-20 Andrew Stubbs
gcc/
* config/arm/arm-protos.h (const_ok_for_op): Add prototype.
* config/arm/arm.c (const_ok_for_op): Add support for addw/subw.
Remove prototype. Remove
On 20/04/11 16:27, Andrew Stubbs wrote:
(*arm_subsi3_insn): Add subw support.
Oh, I should probably say that I've added subw support to arm_subsi3
even though it's not obvious that anything will ever use this.
The existing implementation of arm_subsi3 (sans 'w')
On 20/04/11 16:34, Richard Earnshaw wrote:
On Wed, 2011-04-20 at 13:55 +0100, Andrew Stubbs wrote:
This patch removes some redundant code that caused me some confusion.
It's not possible to construct a constant from multiple ORN
instructions, just as it's not possible to do it wit
On 20/04/11 16:46, Richard Earnshaw wrote:
2011-04-20 Andrew Stubbs
gcc/
* config/arm/arm.c (arm_gen_constant): Move mowv support
(const_ok_for_op): ... to here.
it's movw (not mowv :)
Otherwise OK.
Committed, thanks.
Andrew
On 19/04/11 15:58, Richard Earnshaw wrote:
OK.
2008-12-03 Daniel Jacobowitz
gcc/testsuite/
* gcc.dg/vect/vect-shift-3.c, gcc.dg/vect/vect-shift-4.c: New.
* lib/target-supports.exp (check_effective_target_vect_shift_char): New
function.
Committed, thanks.
changed that.
Is the patch OK?
Andrew
2011-04-21 Andrew Stubbs
gcc/
* config/arm/arm.c: (count_insns_for_constant): Delete function.
(find_best_start): Delete function.
(optimal_immediate_sequence): New function.
(optimal_immediate_sequence_1): New function.
(ar
My previous patch to clean up MOVW support left an unused variable. I
tested building a cross-compiler, but not with -Werror. Others have
reported native bootstrap failing. :(
This patch fixes that problem, and removes the unused variable warning
message.
OK?
Andrew
2011-04-26 Andrew
On 21/04/11 16:58, Joseph S. Myers wrote:
You need to add
%inherit GCC_4.7.0 GCC_4.6.0
GCC_4.7.0 {
}
Ok, done. Is this OK now?
Andrew
2011-04-27 Andrew Stubbs
gcc/
* config/arm/arm.c (arm_init_libfuncs): Change __gnu_f2h_ieee to
__aeabi_f2h, __gnu_f2h_alternative to __aeabi_f2h_alt
On 03/05/11 10:07, Bernd Schmidt wrote:
I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?
I'll take a look.
Thanks for the
ated patch with this change.
OK with a change to do that.
Thanks, I can't commit this until my ADDW/SUBW patch has been committed.
Andrew
2011-05-09 Andrew Stubbs
gcc/
* config/arm/arm.c (struct four_ints): New type.
(count_insns_for_constant): Delete function.
(find_best_start):
On 03/05/11 10:07, Bernd Schmidt wrote:
On 04/15/2011 12:54 PM, Andrew Stubbs wrote:
Ping.
Trying to unblock this...
I think the point is that both examples:
long long foolong (long long x, short *a, short *b)
{
return x + (long long)*a * (long long)*b;
}
and
long long
Ping.
On 20/04/11 16:27, Andrew Stubbs wrote:
This patch adds basic support for the Thumb ADDW and SUBW instructions.
The patch permits the compiler to use the new instructions for constants
that can be loaded with a single instruction (i.e. 16-bit unshifted),
but does not support use of addw
On 20/05/11 10:45, Dmitry Plotnikov wrote:
This patch adds support for 12-bit immediate values for Thumb-2 in ADD and
SUB instructions. We added two new alternatives for *arm_addsi3 which
make use of two new constraints for 12-bit values. Also we modified
costs of PLUS rtx expression.
A alrea
The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
unwind bug when using RealView and libgcc.
It's an old patch that has been in CodeSourcery and Linaro toolchains
for sometime, but somehow escaped being posted here.
OK? (For stage 1?)
Andrew
2008-09-08 Daniel Jacobowitz
On 09/03/11 16:12, Ramana Radhakrishnan wrote:
On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:
The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
unwind bug when using RealView and libgcc.
It's an old patch that has been in CodeSourcery and Linaro toolchain
on SPEC2000 crafty, on an
imx51 board.
An older version of the patch has been used for some time in the
CodeSourcery and Linaro toolchains, so it's fairly well tested.
OK (for stage 1)?
Andrew
2011-03-13 Bernd Schmidt
Andrew Stubbs
gcc/
* config/arm/vfp.md (arm_movdi_vfp): E
On 14/03/11 17:10, Richard Earnshaw wrote:
Finally, alternatives from an insn are normally selected left-to-right
from those available in a pattern, all other things being equal. So
really the A8-only alternative should come after the core registers
alternatives if its less preferable.
OK, I c
On 14/03/11 21:21, Ramana Radhakrishnan wrote:
This is OK for trunk.
Committed, thanks.
Andrew
On 14/03/11 18:17, Richard Earnshaw wrote:
> I think the order should be: not-a8, core-regs, core-regs, only-a8.
Ok, how about this?
I've tested that it still builds spec2k crafty.
Andrew
And again, with the patch ...
On 22/03/11 14:05, Andrew Stubbs wrote:
On 14/03/11 18:17, Richard Earnshaw wrote:
> I think the order should be: not-a8, core-regs, core-regs, only-a8.
Ok, how about this?
I've tested that it still builds spec2k crafty.
Andrew
2011-03-22 Bernd
On 24/03/11 13:22, Richard Earnshaw wrote:
OK
Committed, thanks.
Andrew
On 28/01/11 15:20, Richard Earnshaw wrote:
On Fri, 2011-01-28 at 15:13 +, Andrew Stubbs wrote:
On 28/01/11 14:12, Richard Earnshaw wrote:
So what happens to a variation of your testcase:
long long foolong (long long x, short *a, short *b)
{
return x + (long long)*a * (long
On 30/03/11 16:13, Richard Earnshaw wrote:
2011-02-14 Andrew Stubbs
Julian Brown
Mark Shinwell
gcc/
* config/arm/arm.h (arm_class_likely_spilled_p): Check against
LO_REGS only for Thumb-1.
(MODE_BASE_REG_CLASS): Restrict base
Ping.
On 08/12/10 13:00, Andrew Stubbs wrote:
Here is a patch I'd like reviewed for mainline GCC post 4.6. I don't
think it's suitable for stage 3.
At present, the support for constant loading via immediate operands (as
opposed to constant pools) is not well tuned for Thumb2.
[Ignoring the other issues for now ...]
On 12/04/11 11:02, Richard Earnshaw wrote:
Also, your change to use a double-letter sequence beginning with 'j'
means any hand-written inline assembly code using a single 'j' will
break (that's a backwards compatibility issue for users); is there
really no
FIRST_SGPR_REG is register zero so the compiler always claims this comparison
is redundant. It's right, of course, but I'd have preferred to keep the
comparison for completeness. Probably the "correct" solution is to use an enum
for these values.
gcc/ChangeLog:
* config/gcn/gcn.h (SGPR_
I'm going to commit this soon, but I'd appreciate if anybody could have
a quick look and let me know if anything is obviously broken or doing
things the hard way, or something. Thanks!
Andrew
--
Almost all device-specific settings are now centralised into gcn-devices.def
for the
901 - 1000 of 1052 matches
Mail list logo
